Updated: Comment #11

Problem/Motivation

The plan is to support the following use case:

Allow configuration between Drupal installations that are the same site. For example where we have dev and live installation. The live site was deployed by copying the database and files from the dev site. This means that we do not have a problem with UUIDs as modules have not been enabled on live.

Make the following possible (site A is the dev site and site B is the live site):

  1. Create site A by installing the standard profile
  2. (site A) Create a node type
  3. (site A) Enable forum
  4. (site A) Export configuration
  5. Create site B by Install Drupal and during install use the exported configuration
  6. (site A) Create a view
  7. (site A) Disable forum module
  8. (site A) Export configuration
  9. Synchronise configuration to site B
  10. (site A) Create a view
  11. (site B) Create a view with the same name
  12. (site A) Export configuration
  13. Try and fail to synchronise configuration to site B

Issues in order of priorities

  1. #2095489: Separate out module install config code from import code
  2. #2069373: Race conditions on import if CUD on ConfigEntity A triggers changes in ConfigEntity B
  3. #2133325: Create a site UUID on install and only allow config sync between sites with the same UUID
  4. #2021779: Decouple shortcuts from menu links
  5. #2148211: Use isSyncing flag to prevent creation of configuration entities on synchronisation
  6. #2166065: Replace config_install_default_config with ConfigInstaller service
  7. #1613424: [META] Allow a site to be installed from existing configuration
  8. #2110615: Do not ship with default UUIDs
  9. #2148199: Use snapshot to warn users if the configuration has changed since last import
  10. #2124535: Prevent secondary configuration creates and deletes from breaking the ConfigImporter
  11. #1842956: [Meta] Implement event listeners to validate imports
  12. #2030073: Config cannot be imported in order for dependencies
  13. #1808248: Add a separate module install/uninstall step to the config import process Note we must NOT use default configuration provided by module here - only use configuration from staging directory
  14. #2004370: Batch the configuration synchronisation process

#1515312: Add snapshots of last loaded config for tracking whether config has changed
#1609418: Configuration objects are not unique
#1703168: [Meta] Ensure that configuration system functionality matches expected workflows for users and devs
#1740378: Implement renames in the import cycle
#1831818: Document git config import workflow
#1851018: Improve breakpoint configuration implementation.
#2029771: Having installation profiles in system.module.yml causes config import to fail
#2029819: Implement a ThemeHandler to manage themes (@see ModuleHandler)
#2100043: Dynamically generated default YML use randomized UUIDs.
#2108809: Make config import/export tests pass with standard profile
#2108811: Refactor config import/export tests to allow for easy extension
#2108813: Add fancier config import/export test scenario
#2127573: Stop creating node, comment and custom block fields automatically and provide defaults in CMI
#2124619: Stop creating user_picture field programatically
#2127583: Stop creating administrator role actions programatically

Comments

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

wat :-(

i guess we're thinking this is just the shortest path to a test that will exercise all the broken bits in module install/uninstall and dependency handling? if so, can we make that more explicit? that is, the goal is to exercise those things, not to support this workflow?

aren't we going to encourage people to set up different environments via a 'single starting point'? that is, two installs with the same profile, or a single install that is copied?

because otherwise i have NFI why we think 'do an install with one profile, then do an install with another profile, then use import to make the second install look like the first' is remotely interesting. is that a new best practice we are going to encourage people to use? i'm guessing not, but then i'm left confused why we're building a test for it?

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented

Yes @beejeebus this is just the shortest path to a test that will exercise all the broken bits

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

@alexpott - ok, thanks.

can i suggest that we don't do what's in the OP then? i like that this issue is a meta that groups existing issues, but i really don't think the bits in Problem/Motivation are useful at all.

gdd’s picture

gdd
he/him
Primary language English
Location Portland, OR
CreditAttribution: gdd commented

It seems useful in that it provides a baseline set of functionality that we can shoot for. Its not even a complete baseline, for instance it doesn't test renames or any particularly complicated dependency scenarios. I'm not attached to this specific set of functionality except in that it is extremely easy to test with no additional setup, however I do think its important that we have a set of repeatable steps which represent some basic set of functionality that we can use as a target.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

i'd prefer a different, more targeted approach. there are just so many different permutations here, i think we would do well to do less with each test, so we can have a smaller target for fixing bugs. i just don't think the tests are that hard or as important as actually landing the functionality we need.

for modules: i have a dumb test in #1808248: Add a separate module install/uninstall step to the config import process, but we can expand that to do a lot more. i've been thinking something that does a minimal install, then runs a test for each module in core (with adjustments for dependencies as necessary) on top of that. so the first method does the minimal install + module(s), then export, then we test that we can import that on top of a plain minimal install. we can do similar variations on top of standard, and similar with testing that we can uninstall each module by reversing the process. so, more, smaller tests.

i'd rather we develop specific tests for the soft dependency/ordering issues when we actually have some patches we're working on.

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
Issue summary: View changes

https://drupal.org/node/2121751/revisions/view/2892689/2897281

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
Issue summary: View changes

https://drupal.org/node/2121751/revisions/view/2897281/6677327

mtift’s picture

mtift
he/him
Primary language English
Location Minnesota, USA
CreditAttribution: mtift commented

I definitely like the idea of getting something that works and then improving as needed. If nothing else, this "import standard config on a minimal install" is something we can use as the canonical example (for now). It would be nice to have a procedure that works reliably to demonstrate how the configuration system works, and that someone could, for example, use in a CMI presentation at camps, user groups, in blog posts, etc. (I felt bad for webchick during her live demo at BADCamp when she had to cross her fingers that the configuration system would work, and worse when it did not work.)

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm commented
Issue tags: +Default configuration
xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm commented
Issue summary: View changes
alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
Issue summary: View changes

Completely refocussed issue because default uuids and creation ids have been proved to cause more problems than they solve. Read comments on #2127573: Stop creating node, comment and custom block fields automatically and provide defaults in CMI and #2138559: Replace UUIDs in configuration entities with a creation ID

yched’s picture

yched CreditAttribution: yched commented

From the OP:

(when istalling a module as part of config sync) we must NOT use default configuration provided by module here - only use configuration from staging directory

Totally agreed.

But hook_install() :
- still needs to run.
- but should not perform config writes
Meaning we probably need to pass a $is_syncing param for hook_install()

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented

@yched are you sure about using the is_syncing flag during hook_install. I disagree with this. We need to support the programmatic creation of config entities during module install. This is because, for example, if a contrib module creates a config entity on node type creation then this needs to occur because there is no way to provide this as default configuration.

yched’s picture

yched CreditAttribution: yched commented

We need to support the programmatic creation of config entities during module install

Sure, that point is agreed. What I mean is:
- when enabling a module *as part of a config sync*, we don't import the default config, and similarly we invoke hook_install($is_syncing = TRUE), because, well, we are syncing config :-), and we want to avoid secondary writes in there too.
- other than that, "regular" cases of enabling a module (initial site install, modules admin UI, drush...) run hook_install($is_syncing = FALSE)

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
Issue tags: +beta blocker

We should have a working configuration synchronisation before the beta

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
Issue summary: View changes
alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
Issue summary: View changes
alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
Issue summary: View changes
mtift’s picture

mtift
he/him
Primary language English
Location Minnesota, USA
CreditAttribution: mtift commented
Issue summary: View changes

Removed duplicate issues

alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
Issue summary: View changes
xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm commented
Issue tags: -beta blocker

The beta-blocking parts of this have been listed in #2187339: [META-0] CMI path to beta.

xjm’s picture

xjm
she/her
Primary language English
CreditAttribution: xjm commented
Parent issue: » #2187339: [META-0] CMI path to beta
alexpott’s picture

alexpott
he/they
Primary language English
Location 🇪🇺🌍
CreditAttribution: alexpott commented
Status: Active » Fixed

All of this is done!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.