Problem
Early on in the CMI discussions, it was determined that we had to support partial deployment of configuration - if you add a view, you should be able to deploy just that view. Unfortunately this also caused several architectural problems
- Deploying deletes of configuration is impossible without a full accounting of the items available in each site. To get around this the manifest system was created, however manifests also made deployment more confusing, as it meant every add or delete of a ConfigEntity was associated with two files rather than one.
- It is far more difficult to manage dependencies in a partial deployment scenario. For instance, I could attempt to deploy a field instance without deploying the field definition or the bundle it is attached to. We can add this work to a verification step, but it is a lot more work we are creating for ourselves.
- After doing an import we had to delete all config from the staging directory to prevent it from being imported again. This causes issues with git-based deployment mechanisms and is not completely intuitive.
Solution
Given these and other related problems, we should eliminate the ability to do partial deployments and instead require that the whole config tree be deployed at all times. Additionally, we will ad a UI to export and import the entirety of your config via a single tarball. This will actually increase usability for non-technical users, as it means they no longer have to dive into their directory structure, find the weirdly named config directory, and move files between two differently named directories. This is a pretty big UX win. This decision was made at DrupalCon Portland in a meeting with the CMI maintainers and major contributors, and was approved by Dries.
For those users that are adamant about needing partial deployment, they can write their own by swapping out the import mechanism. This will not be supported by core though.
Comment | File | Size | Author |
---|---|---|---|
#22 | 19-22-interdiff.txt | 699 bytes | alexpott |
#22 | 1998576-22-config-tree-import.patch | 54.5 KB | alexpott |
#19 | 1998576-19-config-tree-import.patch | 53.82 KB | swentel |
#19 | interdiff.txt | 1.13 KB | swentel |
#17 | 16-17-interdiff.txt | 2.69 KB | alexpott |
Comments
Comment #1
tim.plunkettI'm guessing this will complicate #1998204: config_install_default_config() is not safe to use in hook_update_N() a bit.
Right now we're using config_install_default_config() to install new config of a module, but my first idea was to do per-file imports during upgrade. Not sure how that jives with this.
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedi'm working in the 1998576-config-tree-import branch.
here's a work in progress patch, config import and config import UI tests are working.
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedwoops, ignore that patch, here's one with a better rebase.
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedupdated patch, i've removed all the 'manifest' strings i could find in core, and all the tests that referenced manifests are passing for me. oh hai bot.
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous commentedi've added a dumb UI for exporting and importing a config.tar.gz file.
only manually tested by going to admin/config/development/export and admin/config/development/import.
Comment #6
alexpottre #1 it does not complicate it at all :)
The config installer uses a storagecomparer to only create new config... :)
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous commentedhmm, the last patch had some user.module hunks that it shouldn't.
new patch with those removed.
Comment #8
Anonymous (not verified) CreditAttribution: Anonymous commentedupdated patch, adds admin screen menu items, slightly less ugly export form.
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commentedreroll to keep up with 8.x
Comment #9.0
gddUpdated issue summary.
Comment #9.1
gddUpdated issue summary.
Comment #10
gddWe actually don't need to do this anymore. If we always assume a full config tree, then we can just leave the files after doing an import. I guess one question is do we even keep the existing import UI? Or do we just replace it with the one-click download/upload?
I also expanded the issue summary to make it more clear why this is needed.
Comment #10.0
gddUpdated issue summary.
Comment #11
Anonymous (not verified) CreditAttribution: Anonymous commenteddelete - huh, good catch, i'd talked about that but forgot to take it out.
as for the import UI, i think we need it still, just to allow for a sanity check.
maybe we should add a 'skip confirmation of changes'(or whatever wording makes sense), unchecked by default? so people who Know What They Are Doing can skip the import form?
Comment #13
gddI had a thought in the shower today while considering the import screen question. This screen actually provides a lot of very useful information that is lost in the single upload/import operation - whether config is overridden, what config changed, ability to view diffs, etc. What if we made the upload operation just that - upload and extract only. Then after config is extracted to staging, we redirect to the current import screen with a message like 'Your configuration has been uploaded. Please review the changes below and click "Import Changes" to make them active."
This allows us to have the single button upload but still maintain what is really important functionality. We could even remove the current screen from the visible menu to reduce the chances of users ending up there accidentally. Just have 'Download configuration' and 'Upload configuration'.
I really like this idea.
Comment #14
Anonymous (not verified) CreditAttribution: Anonymous commentedre #13 - yep, the current patch just redirects after upload, so you land on the import screen with a message. i'd be happy for it to land that way.
Comment #15
gddOh perfect! I hadn't actually tried the upload side and I guess I missed it in the patch.
Comment #16
Anonymous (not verified) CreditAttribution: Anonymous commentedupdated patch takes out the delete code from the import form.
also added some slightly less stupid UI strings, but i could really do with some feedback on those.
Comment #17
alexpottThis patch is fantastic, the removal of manifests is a huge win, the simplicity of the one button export, import, synchronise is a huge win for usability and less wtf's from new and advanced users.
let's get this in and worry about the strings before string freeze.
rerolled due to userng...
interdiff proves i did no significant change...
Comment #18
swentel CreditAttribution: swentel commentedTwo nitpicks, but I won't set it to needs work for it.
80 chars
Missing end point
Comment #19
swentel CreditAttribution: swentel commentedNitpicks
Comment #20
alexpottThis is RTBC when #19 is green :)
Comment #22
alexpottThis should fix the failing tests....
Comment #23
gddThis is a great patch and a great architectural adjustment that is going to make everyone's lives easier. Huge thumbs up to beejeebus and alexpott. Ship it!
Comment #24
catchMakes loads of sense. Committed/pushed to 8.x.
Comment #25
kim.pepperWow. This is going to make working with config in D8 soooooo much easier. Thank you everyone who worked on this!
Comment #26
xjmRetroactive priority bump. :)
Comment #27.0
(not verified) CreditAttribution: commentedUpdated issue summary.