Closed (fixed)
Project:
Drupal core
Version:
9.2.x-dev
Component:
meetings
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
13 Nov 2019 at 16:04 UTC
Updated:
7 Nov 2020 at 15:34 UTC
Jump to comment: Most recent
Meeting will happen in #config on drupal.slack.com.
Hello and welcome to this CMI 2.0 meeting!
This meeting:
➤ Is for core and contributed project developers as well as people who have an interest in advancing the configuration management capabilities of Drupal.
➤ Usually happens every other Wednesday at 16:00 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/project/drupal/issues/3094199`
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.
Ping @bircher @alexpott @diosbelmezquia @mtodor @ricardoamaro @borisson @jcandan @marcvangend @Kingdutch (Edit https://www.drupal.org/node/3094199 if you don't want to be pinged)
0️⃣ Who is here today? Comment in the thread below to introduce yourself.
| kingdutch | Cool stuff, did not know this was a thing!I’m Alexander (Kingdutch on the interweb). Work as a developer for Open Social. Currently exploring how to move away from features. |
| alexpott | I’m here, as config subsystem maintainer among other things. |
| moshe | Here. I’m a Drupal dinosaur |
| bircher | I am here too :slightly_smiling_face: maintainer of a couple of config_ modules |
| mtodor | A bit late, but here. Maintainer of update_helper module and Thunder distro |
| borisson_ | :wave: later - but still going to try to read/answer on the topics. |
1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread and we'll open threads for them as appropriate.
| alexpott | I think we should discuss the roadmap #3008882: Roadmap for CMI 2 and work out what we should concentrate on. |
| alexpott | I think we should discuss the big new feature we’ve been working towards and next steps - #3033427: [plan] Add support for environment-specific configuration |
2️⃣ Who would like to be pinged for the future meetings
| alexpott | Please ping me :slightly_smiling_face: |
| bircher | @ricardoamaro @borisson_ @marcvangend @dmezquia @mpotter @mtodor ? |
| kingdutch | :wave: |
| dmezquia | Hi |
| dmezquia | Me too |
| mtodor | :+1: |
| bram | :wave: |
| mpotter | @bircher sadly I think I need to be removed. |
| ricardoamaro | Me |
| bircher | @jcandan? |
| borisson_ | Yup - I would like to stay involved :slightly_smiling_face: |
| marcvangend | Yes, although I'm not sure how much free time I'll have left to invest |
| jcandan | please. i keep missing it. |
3️⃣ roadmap - What are the next things to work on?
| alexpott | #3008882: Roadmap for CMI 2 |
| alexpott | That’s the roadmap ^^ - it needs an update |
| alexpott | For me this is missing the work that needs to be done on config validation. Eg. #2869792: [meta] Add constraints to all config entity types |
| bircher | Ah and a recently re-rolled one that I think would be useful (though not with the approach the current patch took) #2925897: Provide a way to validate the current configuration state |
| borisson_ | Are those things that are planned on going into 8.8 still or are they for later? |
| bircher | They won't add backwards incompatibility, and if they do it will be deprecations for Drupal 10. so we can already work on it and it will just get in when it gets in... |
4️⃣ Installing from config and profiles with install hooks. What is the way forward?
| alexpott | That’s #2982052: Allow an install hook in profiles to install from configuration |
| alexpott | The current patch that doesn’t invoke the install profile’s install hook is very interesting. |
| alexpott | OTOH if you look at standard_install() now it is only touching content entities and would be perfectly safe to run during an install from configuration |
| bircher | yes, I think there are a few ways. standard is now safe and we could run the install hook. But there are still plenty of distributions that do more interesting things with its install hooks and with additional install steps. Can we conceive of a way to detect it in some way if it is safe or not? |
| alexpott | Can we conceive of a way to detect it in some way if it is safe or not? |
| alexpott | I don;t think so |
| alexpott | I think the only way is a flag in the info yml. |
| bircher | hmm yea I was afraid that would be the case. But at least that would unblock standard and it would allow profile/distro maintainers to have an easy way to advertise that they support this feature |
| bircher | So if we add a flag to info yml, would we run the install hook together with the modules (ie before the config is imported) or afterwards ie its current place among the install steps? what should be the suggested/recommended way of doing that with extra install steps? |
| alexpott | extra install steps etc… are not a concern of installing from config imo (edited) |
| alexpott | For me, installing from config is something you do with existing sites. Extra install steps are about initial configuration. |
| bircher | Ok so if you have extra install steps that for example create content or ask you extra questions, you just need to guard your code in a if installing from config clause |
| bircher | so when you build a site with umami to demonstrate how to use search_api etc, you could install from config and still get all the content (if the node types still exist etc) |
| borisson_ | Ok so if you have extra install steps that for example create content or ask you extra questions, you just need to guard your code in a if installing from config clause |
| borisson_ | That sounds like a good idea - but I'm afraid on how possible that is. I think that a lot of people will forgot and shoot themselves in the foot |
| borisson_ | I think it should be the other way around, that we disallow changing config in the hook_install unless it is in a hook_install_first_time or something like that? |
| bircher | So you are proposing a new hook that only runs the first time? I am not sure a new hook is necessary as such. Especially if we add a new flag where a developer can say "I paid attention and my hooks work also in the scenario when installing from config" |
| borisson_ | The flag is easier to forget when creating a new version of the profile. if it is in a new hook it is more clear that you have to pay special attention. (edited) |
| bircher | hmm yea that is good argument, but then it could also be hook_that_runs_on_config_install or also run on config install. |
| alexpott | Well the other side of this argument is that getting hook_install correct for regular modules is hard too |
| alexpott | See #2613222: Language module shouldn't alter config in sync mode for example |
5️⃣ Config Environment. We can now exclude (dev) modules from configuration management, but we can not yet manage environments and deploy configuration specific to environments.
| bircher | #3033427: [plan] Add support for environment-specific configuration |
| bircher | While working on this I had an interesting idea: have the environment be only a simple config and not an entity. But then save the environment config object as part of the collection when exporting it. |
| bircher | This would mean that you couldn't edit the configuration of a non active environment for example |
6️⃣ Cross site configuration. features/distributions
| bircher | #3004662: [META] Standardize the way distributions handle config updates |
| bircher | The issue has gotten some feedback, but in order to move forward we need more buy-in from distribution maintainers. |
| bircher | And ideally someone to take a lead on coordinating it |
| kingdutch | Looking from the perspective of Open Social, getting this right is the most interesting for us.Currently we give the users of Open Social not much choice by using features. We’ll have to adopt something when we move away from that method.Currently we’re looking at adopting update_helper which is what Thunder has created. Although I found it difficult to figure out what options are out there and how they replace/complement eachother (cc @bram) |
| bircher | yes update_helper is certainly an interesting approach. Though update hooks are not optional and there is no choice if you want to update or not (as with features). |
| mtodor | @kingdutch be free to ping me if you have some questions regarding update_helper |
| kingdutch | I’m not quite sure I understand what you mean @bircher |
| kingdutch | Will do @mtodor, if you want to follow along with us in the meantime, work is happening in #3092272: [Meta] Moving away from features : ) |
| bircher | update_helper helps you to create a diff of the config you ship initially and the config you are going to ship in the next version. It creates a handy diff format for these config changes. Then it also creates update hooks that apply the diff and record the failed ones so that you as a site owner can see what you might have to do manually. But you as a site owner can not decide not to switch over to the new view etc because update hooks need to be run, and run in every environment (ie also when you have gotten the config updates from the distro and run the new code in production) @kingdutch |
| bircher | I really like to format of the config diffs (aka CUD), but I am not a fan of the update hooks. |
| kingdutch | Ah I see, okay then I was clear on what the update_helper was doing but thought it did a bit more. (@bircher)If I’m not mistaken then Thunder allows users to select which updates to apply @mtodor? What extra module do you use for that?I agree that sitebuilders/developers should be able to have a choice much like when updating a Linux package:Use new configAutomatic merge (if possible)Manual MergeKeep old configWith the option to “pause” and view the differences |
| kingdutch | This ties in with my earlier comment Although I found it difficult to figure out what options are out there and how they replace/complement eachother Maybe a good way to get consensus could be to create a graph of how all the config_* modules work together or alongside one another? |
| mtodor | @kingdutch Unfortunately, we didn’t implement too much options for picking how you want to apply update. We do following:use new module - we always install new moduleuse new config - we always import new configautomatic “merge” - we always apply configuration changes if it’s possible and it’s possible only if specific parts of configuration are in expected state. If site builder has changed something - we will not apply config changes |
| kingdutch | Ah okay, then we may have to invest some time on our end. Although this is fine for most of our internal projects, we expect that other distribution users will have more customisations and may need a bit more choice |
| kingdutch | The CUD that the update_helper module creates would be a good format to standardise around though |
| mtodor | Varbase is using update_helper and they have added some additional functionality to it: https://docs.varbase.vardot.com/updating-varbase/handling-configuration-... |
| mtodor | Ye, CUD is main thing, how you apply that it’s up to you. You can force update always, you can check if it’s safe to update, etc. |
| kingdutch | That looks more akin to our needs, and I think would also work as a good system for Drupal Core.Would have to see how this works with more automated updates (e.g. no UI usage but drush only) |
| mtodor | We are trying to keep sites on Thunder to be as close to provided configuration as possible. Because if site builder picks not to apply our changes, it’s bigger change that next changes provide by us will not be apply properly. If sites are starting to diverge a lot for configuration that we provide, they will not be able to use new changes provided by distribution. |
| mtodor | That’s why we are trying to keep sites on same tract as much as possible. |
| kingdutch | Yeah I understand the challenges. This is mostly why we have been using features up until now.However, I think the use-case of adding a field to a view or removing a block (or changing block order) are very real and should be possible. |
| bircher | Yes so the experiment I made was config_distro. which means that the distro config updates come into your site as part of the development of your site and then once they are part of the config you sync the distro is not involved any more in the deployment process. |
| kingdutch | So with config_distro you can’t apply distro config updates to your site anymore? This means it totally diverges right? So new features will never be added :thinking_face: |
| bircher | No, not at all. config_distro is by itself not doing anything. It is essentially a form that allows you as the site builder/owner to import config from the distribution. As far as I know config_sync is currently the only module that provides a way to declare what that means, but i was meaning to add a way to apply the CUD format. |
| kingdutch | Ooh, re-reading your sentence I understand it better.So contrary to update hooks the config update is done “offline” and then simply included in the cex /cim method of deployment.Yeah that is the flow we’re looking at as well. |
| bircher | So when you have a site that is built on top of a distribution you still want to do the normal config synchronisation for the things you add on top of the distribution. So what happens when you update the distribution your site is built on is: you get the code in your development environment, you run the update hooks, (then with config_distro) you import the distro config updates (where you can ignore some), then you change things further or adjust things that come with other updates, then you export the config and deploy the codebase and on prod you updb and cim |
| kingdutch | Right, yeah |
| bircher | #3080778: New API for config_distro modelled after the new CMI2 config transformation API |
Participants:
kingdutch, alexpott, moshe, bircher, mtodor, borisson_, dmezquia, bram, mpotter, ricardoamaro, marcvangend, jcandan
Comments
Comment #2
bircherComment #3
alexpottComment #4
kingdutchAdded myself to notification list
Comment #7
quietone commentedComment #17
quietone commentedComment #18
quietone commentedComment #19
bircher