Cannot install Reservoir sites using config management best practices

[danepowell]

This problem is identical to one described for Lightning, except a little worse: https://github.com/acquia/lightning/issues/387

Long story short, it's impossible to install a Reservoir site and then import configuration (i.e. from config/default) as you would normally do for a standard configuration management workflow. If you try, you will get errors like this:

Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization. in Drupal\Core\Config\ConfigImporter->validate() (line 728 of docroot/core/lib/Drupal/Core/Config/ConfigImporter.php).
The import failed due for the following reasons:
Entities exist of type Taxonomy term and Vocabulary Tags. These entities need to be deleted before importing.
Entities exist of type Content and Content type Article. These entities need to be deleted before importing.

The reason is that Reservoir does not provide a static/default UUID for its fields, content types (article), and vocabulary (tags). Thus, Drupal picks a random UUID for each at install time. Then when you try to import the existing site configuration, it has a different UUID, so Drupal perceives it as a completely new configuration entity and tries to delete the existing one. But it can't do that if it already contains content.

A simple solution that we're also trying with Lightning is for the profile to provide default UUIDs.

Long-term, there should also be a way to disable the auto-creation of content at install time. This will at least prevent the error (although it will still require running entity-updates, as with the Lightning issue).

[tedbow]

Why doesn't this same situation affect the standard profile which also does not provide default uuid's for the configuration it provides?

[danepowell]

I haven't installed anything other than lightning in a while. I'd have to test, but I suspect this does affect the standard profile.

[damontgomery]

See #33

I delete the part of Reservoir that installs default content and then I can install from configuration.

[danepowell]

I just found this core issue that might help to resolve this in the long run, and also indicates that adding default uuids is a good short term solution: https://www.drupal.org/node/1613424

[danepowell]

Related problem that would also be solved by simply making the auto-creation of demo content optional: #54

[wimleers]

I support #54 — already commented there.

I still don't fully grok why we need our configuration to contain UUIDs — I strongly remember that one of the firm design goals was to not have UUIDs in our config. I even remember (critical?) Drupal core issues to remove UUIDs from default configuration!

So I'd much rather do #54. Would that solve the entire problem?

[wimleers]

Also, if this is a best practice (which would directly contradict my past experience), then where is it documented on drupal.org?