>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3345008. --> Reported by: [hestenet](https://www.drupal.org/user/54034) >>> <h2>Transcript</h2> <h2>0&#65039;&#8419; Who is here today? Comment in the thread below to introduce yourself and tell us why you are joining us.</h2> <table> <tr> <td>hestenet (he/him)</td> <td>Tim from the DA kicking things off :wave::skin-tone-3:</td> </tr> <tr> <td>bircher</td> <td>:wave:</td> </tr> <tr> <td>thejimbirch</td> <td>Jim from Kanopi :wave:</td> </tr> <tr> <td>penyaskito</td> <td>:hand::skin-tone-4:hello! Christian from sunny Sevilla today</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Bob from St Charles IL, western burbs of Chicago</td> </tr> <tr> <td>kreynen</td> <td>Kevin from CU&hellip; has it been 2 weeks already?</td> </tr> <tr> <td>dww</td> <td>Derek :wave:</td> </tr> <tr> <td>Warped</td> <td>Dave in Chicago</td> </tr> </table> <h2>1&#65039;&#8419; Do you have any topics to propose for the meeting today? Feel free to propose them in this thread, and then I will give them their own unique threads for discussion.Conversation moving slow? Go ahead and open your own thread in the next numeric order.</h2> <table> <tr> <td>hestenet (he/him)</td> <td>@bsnodgrass (he/him) - I will have to run to an appointment, so if you can keep an eye out for new topics that would be a big help.</td> </tr> </table> <h2>2&#65039;&#8419; Idempotent recipes.Or how to unblock the circular recipes dependencies.We should get inspired by Ansible for how recipes can be applied again and again. The core of the recipe system should make it easy to create idempotent recipes so that applying a recipe again as part of another recipe is a no-op. If recipes are meant to apply over and over again this would also solve the issue of how to update with an updated recipe: You just run the updated recipe.</h2> <table> <tr> <td>hestenet (he/him)</td> <td>Raised by @bircher - and related to concerns raised by @eclipsegc as well.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>In principle this sounds great... but I don't really have the foggiest how we would start :sweat_smile:</td> </tr> <tr> <td>bircher</td> <td>I am not an expert Ansible user, the concept of idempotency is probably one of its key ingredient of success, in the end it just remotely executes bash or python. we just execute php in Drupal so not the code we need but the approach, Ansible is also configured with yaml</td> </tr> <tr> <td>penyaskito</td> <td>not sure if I got this right, but if recipe adds a content_type A with fields X and Y, and the updated recipe adds A with X, Y and Z, that's not idempotent by definition (an updated recipe is a different recipe by definition?).Also, don't think we are tracking which recipes are applied in a site.In terms of methods, I expect that if the recipe adds the permission P to the role R, if R already has P it's a nop, not an error/duplication.</td> </tr> <tr> <td>penyaskito</td> <td>something tells me that if I have 2 (or N) recipes with circular dependencies, that's bad design and I should have 1 recipe, or any of those dependencies should be optional. I might be missing usecases here though.&nbsp;(edited)</td> </tr> <tr> <td>eclipsegc</td> <td>So, this sounds great on the surface, but configuring a server is not really the same as configuring a Drupal instance. A lot of what&rsquo;s done in Drupal is stateful by nature and if that state changes, your problems around this space persist.</td> </tr> <tr> <td>eclipsegc</td> <td>Case in point:If a recipe creates a content type and view and another recipe modifies the view (this a dependency) then you can&rsquo;t really apply the initial view creation command again. And with any op that has schema implications it&rsquo;ll be even more complicated and brittle.</td> </tr> <tr> <td>eclipsegc</td> <td>Also, user configuration will throw this into disarray</td> </tr> <tr> <td>eclipsegc</td> <td>If you&rsquo;re going to do it, each item needs its own full instruction set. Create this view, add this relationship, add this field. But again views is kind of the easy example. Schema related things will be much harder.</td> </tr> <tr> <td>Warped</td> <td>That's why I wish there were view templates. You could copy them to a new view, but couldn't modify the template. Only the originator could modify the template. But that would require the ability to see changes and apply to the copy in a structured way.</td> </tr> <tr> <td>Warped</td> <td>Maybe including revisions to compare the differences.</td> </tr> <tr> <td>bircher</td> <td>@penyaskito well yes applying an updated recipe should get you to the updated config, that is the beauty of it. Also we don't need to track which recipe has been applied. The use case is not so much circular dependencies but recipes composed of other recipes that share the same ingredient (think of the editor role)</td> </tr> <tr> <td>bircher</td> <td>@eclipsegc I wouldn't be too fast in dismissing this idea. I don't know enough about Ansible to know how it is done there, hence raising the topic to explore what the similarities are.Also, when you write python or bash scripts you can do all sorts of stateful things etc, it is the restriction/ideal of idempotency that makes it great.And for your example, yes if you run two recipes the expectation is that if you run them again you get to the same state, you need to run both again. (for example as part of a third recipe)I guess what we need is a way to define when a recipe is "happy" so you can say my recipe is happy if this content type exists and has a display, and then the exact configuration is "free" or it wants the configuration to be exactly as defined. Or something in-between... Think of the times you exported things to features and then reverted said feature, but crossed over with config ignore that lets you say that part of the config is meant for modification in production.</td> </tr> <tr> <td>sonfd</td> <td>@alexpott mentioned something related to this a while ago that I think is an interesting idea.The current recipe level inclusion does not work because it entangles the recipes too much. The idea is to be able to say something like if this role does not exist you can get it from this recipe.So with that approach, perhaps installing many recipes via the recipes section of a recipe.yml is not the approach, but rather listing dependencies and their default source location? :shrug:dependencies:<br> media.type.image: my_image_recipeor maybe that would go under the config section?</td> </tr> <tr> <td>bircher</td> <td>@Warped this is an implementation detail and not the ansible discussion I wanted to have, but imagine you have a folder in your recipe with config and then a configuration in the recipe for that config in the style of config ignore that lets you define what part of the config you want to update/revert if it exists already. This would even be possible with the current config actions system if there was a way to pass which recipe is being applied to the method (for example via annotation or via a secial name for the parameter)Then the recipe would be your template edited only by the recipe creator and you could diff it with git if you don't gitignore the recipes.</td> </tr> <tr> <td>bircher</td> <td>@sonfd yes that comes from the discussion in Prague, the idea is that you don't list "dependencies" but you say "I need this config to exist, run that recipe if it doesn't"</td> </tr> <tr> <td>Warped</td> <td>I was addressing the ability to update without destroying changes, or being restricted because they were changed by the site builder, when you wanted to update the recipe. Even if 2 recipes changed the same item, with revisions, they could pick which version to base their changes on, or apply just the changes. But once you allow them to chanflge a view, that causes more issues, where just having a view as a template leaves it under total control of the recipe without changing any views the site builder might be using. Ansible modules are written mostly in Python. You give it the state you want it to be in, not the command to get there. So installing a program just had the state of installed. If it is already installed, there is no change. If you used a script to install, the c9mmand would fail because the program is already installed. Unless you added logic to check.</td> </tr> <tr> <td>bircher</td> <td>Yes the parallel I see with Ansible is the module (ie the python code) corresponds to the plugin in drupal (aka the config actions). Then the recipe just defines what it would like etc. I think it will be up to each plugin to make sure to behave well (ie no-op when it is considered to be in a good state already)As far as I know, there is nothing technically preventing you from making non-idempotent ansible modules, just more senior developers telling you that you are doing it wrong.</td> </tr> <tr> <td>bircher</td> <td>I think the idea with the template is what recipes are, just much more in addition. You need to let go of the idea that you as the maintainer of a distribution or author of a recipe are in control of the config which is active on the site. You can write update hooks if you want the site builders to not have a choice of whether or not they want your change. But the idea with recipes is that I can chose which ones you want to apply. Me as the site builder can just apply the recipes I want, and I can change things on my site as I please. And if I don't like it then I can always revert to how it was before by just importing the config from the sync directory (because I was cautious enough to export the config before I was playing with your recipe).</td> </tr> <tr> <td>bircher</td> <td>For example, I think it would be cool to have a "features UI" to build a recipe based on a diff between the active config and another config storage. (like the sync directory or some snapshot storage). Like automatically generated recipe that describes just the difference of the config. I could then create this recipe, apply the updated recipes and then apply mine again. This would update the things I haven't changed but would retain the things that I did change in the config thd recipe updated.</td> </tr> <tr> <td>bircher</td> <td>that would be a fun contrib project which could borrow a lot of code from Config Split</td> </tr> <tr> <td>Warped</td> <td>I think there would be too much overlap. For example, adding a field, changing a sort, or selection on a view. Config would not separate my changes from the recipe, especially if a new version of the recipe had a change for the view. My config would have the view as it was before the update. Applying my config after the update would wipe out any new view changes. But if views were revisions, you could get a diff between versions, and choose to apply those changes to a different version. And if a recipe had a template view, I could copy any revision and use for mine. Or apply my changes to a copy of the latest version of the template view. Updating the recipe couldn't change my setup because they are just copies of the recipe's view, or other content.</td> </tr> <tr> <td>bircher</td> <td>@Warped if you think the "recipe override" would keep the whole changed config as an override then yes that would be true. But nothing says that this has to be the case. Config Split 2.x already does keep only changes today. So there would only be an overlap if the updated recipe changed something that you already changed and in that case your change would win. But you would see that when applying the recipes as it would change things back and fourth. I think apart from it suffering the same difficulties with sorting and addressability that config split has, it would work rather well. In any case this could be completely contrib and we could add it to core at a much later stage.</td> </tr> <tr> <td>bircher</td> <td>But this would probably deserve its own :thread: as it is completely independent from the Ansible discussion</td> </tr> </table> <h2>Does the recipes initiative have DrupalCon plans? Specific goals for contribution day? Cc @thejimbirch @nerdstein&nbsp;(edited)&nbsp;</h2> <table> <tr> <td>nerdstein</td> <td>I was able to discuss it briefly with @thejimbirch and @bsnodgrass (he/him) - I think @thejimbirch was on point for some follow up. Ive been slammed lately so I don&rsquo;t know how much I can responsibly sign up for</td> </tr> <tr> <td>thejimbirch</td> <td>I will be attending DrupalCon, and have a presentation slot for the initiative.</td> </tr> <tr> <td>thejimbirch</td> <td>@G&aacute;bor Hojtsy (he/him) If you could guide me what else I should be putting together, I would appreciate it.</td> </tr> <tr> <td>G&aacute;bor Hojtsy (he/him)</td> <td>Not saying you should put it together. The question is more about whether the initiative has contribution (achievement) goals for contribution day at DrupalCon. Will there be people working on the initiative at the contribution day in an organized fashion? And if so do we know roughly what they plan to work on.</td> </tr> <tr> <td>nerdstein</td> <td>there are no plans ive seen up to this point.</td> </tr> </table> <h2>Can we update config schema through recipes? Something similar to hook_config_schema_info_alter.</h2> <table> <tr> <td>bircher</td> <td>No, not directly. But your recipe can install a module that has a hook_config_schema_info_alter implementation of course</td> </tr> <tr> <td>bircher</td> <td>@narendraR does this answer your question?</td> </tr> <tr> <td>narendraR</td> <td>Actually I have a custom module which does this thing and I wanted to convert it into a recipe. :blush:</td> </tr> <tr> <td>bircher</td> <td>Ah, ok. Well recipes are stateless and by themselves not persistent. They represent a series of things to do on your site. Not alter it the way you would know from an alter hook.</td> </tr> <tr> <td>bircher</td> <td>their change is applied when the recipe is applied, Recipes do not have any impact on a running site</td> </tr> <tr> <td>bircher</td> <td>But you could still do what you asked for in a contrib/custom module</td> </tr> <tr> <td>bircher</td> <td>it would require a module with the hook and some logic to alter the data and a store for where you save this data, and then a config action plugin that you can trigger from your recipe giving it the data to save in the store</td> </tr> <tr> <td>bircher</td> <td>I mean.. technically you can do this.. but maybe you would be better served not doing that this way</td> </tr> <tr> <td>narendraR</td> <td>I thought as configs can be updated through config:actions in recipe, what if we need to update the existing schema to use configurations added</td> </tr> <tr> <td>bircher</td> <td>well you can think of the schema as "code", if not then you would need this module that I described that can define the config schema with config..</td> </tr> <tr> <td>bircher</td> <td>but maybe it is not a great idea, you have to be careful with hook_config_schema_info_alter! Usually the config schema and the code that uses this config are coupled, so if you just go and change the schema, you probably also need to change the code that deals with it or it will most likely fail</td> </tr> <tr> <td>narendraR</td> <td>Got it. Thanks. :pray:</td> </tr> <tr> <td>eclipsegc</td> <td>Think of a recipe like you would a developer. It is just a canned set of interactions with a Drupal site to achieve a desired outcome. You still build all the same Drupal stuff to get there (modules, hooks, etc)</td> </tr> </table>