- We have a shiny new configuration system, but the primary workflow we are targeting is not in place - push configuration files to a second site and have that new configuration take effect.
- Implement this functionality.
- Files pushed to a new site should not take effect immediately, something will have to be kicked off to accept them.
- There needs to be a place in admin to do this, but also an API that can be hooked into by Drush and other tools.
- When a reload happens, modules need to be notified of these changes so that they can act on it.
- This notification has to happen in a specific order (new node types need to be created before field instances can be added, same between fields and instances, etc...)
- This notification has to include extensive information about the config since modules may want to act on changes to other modules' config.
- We need to avoid race conditions wherein the code that has been pushed to the second server gets overwritten by configuration changes happening on the live site.
- When config is reloaded a new hook is fired for modules to respond to. This hook passes on pointers to the old config (currently in the active store) and the new config (currently in the files.)
- Modules examine the differences between these two in order to determine the actions they need to take. New additions can be considered a create, missing configuration can be considered a delete.
- Modules are called in the order of the dependency chain defined in info files.
- Aside from this, the work to be done is left entirely to the modules to detect and react to.
- The idea of using the module dependencies for ordering is entirely experimental and may not work at all. It will need extensive testing and research. Other ideas welcomed.
- This will require a bit of reworking of the current class architecture to achieve properly.
- There are two thoughts as far as avoiding race conditions.
- Currently files are automatically written when configuration changes are made. This means that when files are pushed, in order to avoid changes being overwritten, the admin on tha target site would essentially need to be set to be read-only until the configuration is reloaded. This is a feature we plan on adding anyways, but this switch would need to be flipped manually before config is pushed/pulled.
- The other option is that we don't write files automatically, instead we just write the active store. When you want to push config to the live site, you have to manually export the config, commit it, and push it live. This adds a step for end users, but reduces complexity in the deployment process.
- The ideal target use case for this is the field system. If we can make that work, we should be in pretty good shape.
- Further discussion can be found at http://groups.drupal.org/node/190729
PASSED: [[SimpleTest]]: [MySQL] 37,241 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 37,313 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch config.import.161.patch. Unable to apply patch. See the log in the details link for more information. View