Document that Acquia Connector should never have its configuration exported to code on Cloud

[webkenny]

I am pasting the issue here from JIRA...

We need to document in BLT that developers should not include Acquia Connector settings in a traditional configuration export. You cannot reproduce this locally because the file mount doesn't exist and therefore this code never runs:

/**
 * Acquia Cloud settings.
 */
if ($is_ah_env && file_exists('/var/www/site-php')) {
  require "/var/www/site-php/{$_ENV['AH_SITE_GROUP']}/{$_ENV['AH_SITE_GROUP']}-settings.inc";

  // Store API Keys and things outside of version control.
  // @see settings/sample-secrets.settings.php for sample code.
  $secrets_file = sprintf('/mnt/gfs/%s.%s/secrets.settings.php', $_ENV['AH_SITE_GROUP'], $_ENV['AH_SITE_ENVIRONMENT']);
  if (file_exists($secrets_file)) {
    require $secrets_file;
  }
}

I figured it out by running a bunch of tests and discovering the module couldn't be enabled (thus it was not able to load all the routes). It started with a simple error message: Unable to install ModuleNamespace Acquia Connector, acquia_connector.settings already exists in active configuration.

Once I dug around from there it was clear this was ONLY possibly on Cloud using BLT hence why it worked locally. Something pretty important we need to document as "Before you Deploy to ACE, know this!"

[webkenny]

Actually now that I've given this some thought, I wonder if there's an opportunity for automation here. Let's say someone runs vm:init and is using Drupal VM. Couldn't we theoretically copy down the configurations from cloud into a matching directory in the VM? Or, if we want to get really fancy - couldn't we create said file using Cloud API regardless of environment?

CC @grasmash for thoughts.

[grasmash]

I'd prefer to start simple.

Can you explain the root cause of the issue? Does Acquia Cloud already have connector configuration somewhere? Why does it cause a problem?

[webkenny]

Fair point. So here's what we do on Cloud:

• We recommend that people keep "sensitive information such as config keys" in the file mount. I hate this approach but it is what it is. (Side note: I don't believe a SSH protected repository should not have mission critical configuration residing in it but, again, it's already out there)
• Partner comes in and hears us say, "All configuration in code!"
• Partner develops a module with the connector information inside it via Config Mgmt.
• Deploy code.
• Try to enable module.
• Fatal error.

So we need some form of documentation that outlines we want all config in code except these things which we specifically tell you not to.

[grasmash]

This doesn't explain why putting connector config in config management causes a fatal error. Why does it happen? Does the config already exist in the mnt dir? Is there any error due to duplicative config?

[webkenny]

Correct. Previously exists in the /mnt. When you enable a module that defines configuration which previously exists (as it would when its included in settings.php) Drupal core cannot enable Acquia Connector (fails in the middle) and then subsequent requests are a fatal error because the routes for Connector aren't defined. Once you clear cache it stops the error but the module still cannot be enabled.

Make more sense?

[grasmash]

Yes that makes more sense. In this case, is there a way we can check to see if the configuration exists elsewhere before including it? What would that look like?

[danepowell]

Seems related, although it's almost a year old now: https://www.drupal.org/node/2635138

[grasmash]

I don't think that there's really a place for this documentation in BLT, but I'm happy to have this issue indexed via Google. My suggested workaround would be to use features to import the config rather than using Core CM. This should prevent errors related to importing duplicate config. This recommendation is already documented.