Closed (fixed)
Project:
Drupal core
Version:
9.2.x-dev
Component:
meetings
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
10 Sep 2020 at 09:25 UTC
Updated:
7 Nov 2020 at 15:39 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 Tuesday 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/3170190`
➤*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 @phenaproxima @balsama @wouter @mikemadison (Edit https://www.drupal.org/project/drupal/issues/3173852 if you do or don't want to be pinged, or want to add topics for next time.)
---
0️⃣ Who is here today? Comment in the thread below to introduce yourself.
| mikemadison | :wave: Mike Madison from Acquia |
| alexpott | :wave: Alex from London, UK |
| moshe | here |
| bircher | Hi everyone |
| larowlan | Lee, Australia, late, timezones |
1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread and we'll open threads for them as appropriate.
| bircher | Anyone wants a real call? |
2️⃣ Consensus on what to do with excluded modules
| bircher | The issue is #3102435: Config exclude Drupal core feature doesn't work (Drupal 8.8.1 or later) |
| bircher | So on one hand I like that we add an exception so that transformations can stop it, on the other hand in this particular case I think it would lead to abusing the feature. ie you would be inclined to "exclude" a development module on production so that it would complain if it was part of the sync config by accident. But that is fundamentally not how one should use this feature because it would allow one to install said module and then never be able to uninstall it via a deployment and one would never know |
| alexpott | I really struggle with this one because when I used it - the new feature didn’t meet my expectations |
| alexpott | I get the feeling we should warn users if there is config that is marked as excluded in the import |
| bircher | @alexpott so your expectation would be to import what is currently active config, ignoring what is in sync since when you export the sync config will be removed anyway? |
| alexpott | Well I think that the current behaviour is surprising |
| alexpott | I think that we should either warn or stop. |
| bircher | Warning is better |
| bircher | I think |
| bircher | we can also stop.. but then it would be a different setting in my opinion |
| bircher | ie, safeguard on prod to never allow importing a dev module |
| alexpott | Well… not stop kinda breaks a contract we have |
| alexpott | Which is if you import and it succeeds (ie. makes changes) and you then run export - the config export should not change |
| bircher | what do you mean? |
| bircher | ah |
| bircher | (slack being slow today) |
| bircher | Yes I see the point in that, but stopping the import will make transitioning more difficult. But I am totally fine with that. I am more on the fence about setting this on production in order to "safeguard" when that makes it more dangerous |
| bircher | In my limited view the feature allows you to automatically disable a module before you export. so when you import with the module enabled then the feature kicks in afterwards.. so it is a "action" in that sense.The contract that it still follows is that if you export and then import nothing changes on the import |
3️⃣ Adding ConfigStorageTestTrait to help tests using the core storage transformation API.
| bircher | The issue for config filter is: #3173393: Add test traits to harmonize tests. |
| bircher | should we add this to core too? |
| bircher | and does this count as a feature request and can only go to 9.1+ or also to 8.9? |
| alexpott | Test only stuff has some latitude |
| alexpott | If you want this in core and can make a case that it helps modules bridge the 8 to 9 gap and it doesn’t result in changes to existing things then I’d like to think we can make the case to do this. |
| bircher | I think it doesn't necessarily bridge the gap between 8 and 9 but it bridges the gap between config filter and the core api, ie it provides a framework to test how your config transformation event listener is supposed to work |
Participants:
mikemadison, alexpott, moshe, bircher, larowlan
Comments
Comment #2
bircherComment #3
bircherComment #5
quietone commentedComment #10
quietone commentedComment #11
bircher