18:00:10 <felixfontein> #startmeeting Ansible Community Meeting 18:00:10 <zodbot> Meeting started Wed Aug 4 18:00:10 2021 UTC. 18:00:10 <zodbot> This meeting is logged and archived in a public location. 18:00:10 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:10 <zodbot> The meeting name has been set to 'ansible_community_meeting' 18:00:10 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539 18:00:10 <felixfontein> abadger1999 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro cidrblock thaumos zbr: ping! 18:00:14 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics 18:00:17 <felixfontein> #topic Updates 18:00:17 <briantist> o/ 18:00:20 <felixfontein> #chair dmsimard gwmngilfen-work cidrblock[m] briantist 18:00:20 <zodbot> Current chairs: briantist cidrblock[m] dmsimard felixfontein gwmngilfen-work 18:00:39 <tadeboro> o/ 18:00:53 <abadger1999> hello 18:01:06 <felixfontein> #chair tadeboro abadger1999 18:01:06 <zodbot> Current chairs: abadger1999 briantist cidrblock[m] dmsimard felixfontein gwmngilfen-work tadeboro 18:01:16 <cyberpear> o 18:01:21 <cyberpear> o/ 18:01:24 <felixfontein> #chair cyberpear 18:01:24 <zodbot> Current chairs: abadger1999 briantist cidrblock[m] cyberpear dmsimard felixfontein gwmngilfen-work tadeboro 18:01:29 <samccann> o/ 18:01:51 <felixfontein> #chair samccann 18:01:51 <zodbot> Current chairs: abadger1999 briantist cidrblock[m] cyberpear dmsimard felixfontein gwmngilfen-work samccann tadeboro 18:02:09 <dmsimard> #info Ansiblefest registrations are opened, sign up to attend september 29-30th 18:02:23 <dmsimard> #undo 18:02:23 <zodbot> Removing item from minutes: INFO by dmsimard at 18:02:09 : Ansiblefest registrations are opened, sign up to attend september 29-30th 18:02:29 <dmsimard> #info Ansiblefest registrations are opened, sign up to attend september 29-30th: https://www.ansible.com/ansiblefest 18:03:30 <geerlingguy> will check in but can't make it to the full meeting today :( 18:03:32 <dmsimard> #info Contributor summit registrations will be available soon, current plan is https://hackmd.io/@ansible-community/contrib-summit-202109 18:03:37 <geerlingguy> I just want to make sure that IRC/Matrix bridge works and I'll be happy and take my time to slowly consider moving someday :D — as it is I have too many chat things open and at least my IRC client only uses like 30 MB of RAM. 18:03:51 * geerlingguy also needs to get cranking on 'Fest presentation 18:03:55 <dericcrago> speaking of ansiblefest / contributor summit, the community team is trying to organize a sprint / hackathon. We'll have more info in the coming weeks. 18:04:13 <gwmngilfen-work> geerlingguy: +1 18:04:30 <felixfontein> #chair geerlingguy dericcrago 18:04:30 <zodbot> Current chairs: abadger1999 briantist cidrblock[m] cyberpear dericcrago dmsimard felixfontein geerlingguy gwmngilfen-work samccann tadeboro 18:04:55 <dmsimard> geerlingguy: no rush, IRC and matrix will continue to be available side-by-side for the foreseeable future https://xkcd.com/1782/ :) 18:05:13 <abadger1999> #info ansible-4.4.0 scheduled for next Tuesday. If you have collections to release, do so before then (or let me know and I'll wait a few hours for you to get a release out on Tuesday) 18:05:20 <abadger1999> #undo 18:05:20 <zodbot> Removing item from minutes: INFO by abadger1999 at 18:05:13 : ansible-4.4.0 scheduled for next Tuesday. If you have collections to release, do so before then (or let me know and I'll wait a few hours for you to get a release out on Tuesday) 18:05:33 <abadger1999> #info ansible-4.4.0 scheduled for next Tuesday. If you have collections to release, do so before then (or let abadger1999 know and he will wait a few hours for you to get a release out on Tuesday) 18:05:38 <acozine> o/ 18:05:49 <felixfontein> #chair acozine 18:05:49 <zodbot> Current chairs: abadger1999 acozine briantist cidrblock[m] cyberpear dericcrago dmsimard felixfontein geerlingguy gwmngilfen-work samccann tadeboro 18:06:01 <felixfontein> any more updates? :) 18:06:21 <dmsimard> abadger1999: That reminds me we didn't set up a topic to chat about a revised release schedule for ansible 5, we can do that today if it's not last minute 18:06:37 <abadger1999> <nod> wfm 18:06:42 <felixfontein> is there already a proposal for a revised schedule? 18:06:56 <dmsimard> Not AFAIK, hence my note 18:07:03 <felixfontein> ok, let's start with matrix :) 18:07:04 <felixfontein> #topic Proposal: Ansible Community to accept Matrix as an equal partner to IRC 18:07:07 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/36 18:07:10 <felixfontein> #info Proposal to vote on: https://github.com/ansible-community/community-topics/issues/36#issuecomment-892738232 18:07:34 * dmsimard quickly creates topic for ansible 5 18:07:52 <gwmngilfen-work> are there more discussions/question folks have? 18:08:09 <gwmngilfen-work> happy to answer them, as acozine said, it's important folks are heard 18:08:20 <felixfontein> with the current wording, I think it's good 18:08:38 <gwmngilfen-work> also worth restating, this is not once-and-done, I'll be gathering feedback as we go 18:08:57 <felixfontein> since we support both IRC and Matrix, this should accomodate both existing IRC users as well as new users who prefer Matrix over IRC 18:09:14 <dmsimard> I agree with the sentiment that there is a distinction between first choice and default (vs potentially deprecating IRC) 18:09:37 <gwmngilfen-work> felixfontein: thats the plan - the test of the conferencing yesterday cemeted that we can include both sets of users 18:09:47 <gwmngilfen-work> *cemented 18:09:55 * acozine looks at current docs 18:09:57 <gwmngilfen-work> dmsimard: yep, i've updated the wording 18:10:38 <jillr> o/ sorry I'm late (catching up on scrollback...) 18:10:42 <felixfontein> #chair jillr 18:10:42 <zodbot> Current chairs: abadger1999 acozine briantist cidrblock[m] cyberpear dericcrago dmsimard felixfontein geerlingguy gwmngilfen-work jillr samccann tadeboro 18:10:54 <felixfontein> ok, if nobody has further questions, should we vote? 18:11:19 * gwmngilfen-work is excited 18:11:30 <acozine> voting sounds good 18:11:50 <felixfontein> let's have two votes, for both parts of https://github.com/ansible-community/community-topics/issues/36#issuecomment-892738232 18:11:57 <cidrblock[m]> I'm ready :) 18:12:02 <felixfontein> VOTE: We accept Matrix as an official chat platform (alongside IRC) 18:12:08 <acozine> +1 18:12:09 <tadeboro> +1 18:12:10 <cidrblock[m]> +1 18:12:11 <felixfontein> +1 18:12:12 <samccann> +1 18:12:14 <dmsimard> +1 18:12:17 <gwmngilfen-work> +1 18:12:20 <dericcrago> +1 18:12:23 <briantist> +1 18:12:28 <cyberpear> +0 18:12:32 <gwmngilfen-work> (we have a +1 from gundalow on GH too) 18:12:37 <abadger1999> +1 18:13:40 <jillr> +1 18:13:52 <acozine> geerlingguy: you voting? 18:14:53 <felixfontein> he said he won't be around all the time 18:14:58 <acozine> ah, I missed that 18:14:59 <felixfontein> #agreed We accept Matrix as an official chat platform (alongside IRC) 18:15:23 <gwmngilfen-work> yay! 18:15:27 <felixfontein> VOTE: We update our docs, etc, to promote Matrix as the first-choice chat option *for new community members* (in particular, IRC is not deprecated) 18:15:29 <cidrblock[m]> w00t! 18:15:34 <cidrblock[m]> +1 18:15:37 <gwmngilfen-work> +1 18:15:38 <felixfontein> I added the last sentence to make sure that nobody gets the wrong idea here :) I hope it's ok? 18:15:41 <dericcrago> +1 18:15:43 <felixfontein> +1 18:15:46 <gwmngilfen-work> felixfontein: fine with me 18:15:58 <dmsimard> +1 18:16:08 <tadeboro> +1 18:16:09 <acozine> +1 18:16:14 <samccann> +1 18:16:22 <jillr> +1 18:16:33 <acozine> I can have a docs PR for this change done in a day or two 18:16:41 <abadger1999> +1 18:16:55 <gwmngilfen-work> acozine: i'm looking at https://docs.ansible.com/ansible/latest/community/communication.html#communication in particular, happy to do the legwork if you wish 18:17:11 <felixfontein> #chair 18:17:11 <zodbot> Current chairs: abadger1999 acozine briantist cidrblock[m] cyberpear dericcrago dmsimard felixfontein geerlingguy gwmngilfen-work jillr samccann tadeboro 18:17:17 <gwmngilfen-work> there's probably other places and things to write, it's next on the list :) 18:17:27 <acozine> gwmngilfen-work: thanks, there are some other things I wouldn't mind updating on that page as well 18:17:38 * gwmngilfen-work is distracting from the vote though 18:17:41 <abadger1999> There's a bunch of other places that refernece irc channels too. I have a PR that updated those from freenode to libera that you can use to find all the places 18:17:48 <cyberpear> -1 I think IRC should stay primary, but 18:18:00 <gwmngilfen-work> abadger1999 thanks 18:18:01 <acozine> cyberpear: oh interesting, why? 18:18:45 <cyberpear> You don't have to create any kind account at all to participate. 18:19:14 <briantist> I was going to say +0, for a similar reason, in that I don't necessarily see why we need to promote one or the other as a first choice. But I don't feel very strongly about it either. 18:19:28 <abadger1999> gwmngilfen-work: https://github.com/ansible/ansible/commit/80e7e1a17cb6aaf10e289e671fc382a614018e6e 18:19:30 <cyberpear> I can tell someone, "go to webchat and ask you question there" 18:19:31 <acozine> that's a good point, we can definitely include that in the docs about how to communicate by real-time chat 18:20:01 <felixfontein> is this something that can be solved by the matrix guest feature? 18:20:06 <acozine> help people understand the tradeoffs of using one technology or the other 18:20:07 <tadeboro> But is this really true? I know I had to register my nick for quite a few ansible-related channels. 18:20:09 <gwmngilfen-work> thats fair, however many channels (including this one iirc) have registrations required 18:20:13 <felixfontein> (I remember that gwmngilfen-work mentioned it is currently broken tough) 18:20:18 <abadger1999> yeah, what tadeboro said. 18:20:41 <gwmngilfen-work> guest accounts were a thing, and I hope will be a thing again, yes 18:20:58 <tadeboro> And registering a nick is not fun if you come from a land of discord ... 18:21:21 <gwmngilfen-work> tadeboro: precisely 18:21:27 <felixfontein> registering isn't fun when using matrix to connect to some ansible channels either :) 18:21:27 <acozine> it's more "what kind of inconvenience do you prefer" I'd say 18:21:27 <cyberpear> yeah, apparently this channel requires registration... I'm generally opposed to that except when actually experiencing spam, etc 18:21:55 <felixfontein> ok, back to the vote - any more votes, or vote changes? 18:22:40 <felixfontein> right now I think we have a majority (of council members) for +1 (with 6 votes), and one -1 18:22:44 <gwmngilfen-work> felixfontein: i hope i can standardise a bridge exception to that, its what we have here 18:22:59 <felixfontein> gwmngilfen-work: that would be awesome :) 18:23:17 <gwmngilfen-work> there's 25 rooms to do though, so I've been putting it off 18:23:33 <tadeboro> I countd +10, -1 right now. 18:23:46 <acozine> any chairs who haven't voted? 18:23:58 <felixfontein> tadeboro: that's correct (if you count everyone) 18:24:22 <tadeboro> Ahh, OK, forgot we can count things in two different ways ;) 18:24:56 <felixfontein> I assumed it's clear that there's a large majority of people who voted for it anyway :) 18:25:04 <acozine> yep 18:25:20 <felixfontein> #agreed We update our docs, etc, to promote Matrix as the first-choice chat option *for new community members* (in particular, IRC is not deprecated) 18:25:26 <gwmngilfen-work> thanks everyone! and especially thanks to those with doubts for the trust - I'm always happy to have more feedback on what's working or not in the future. 18:25:39 <felixfontein> ok, great, since nobody had further votes, I think we can stop with this topic (at least for today) :) 18:25:59 <gwmngilfen-work> I'm going to celebrate with something that only really works on Element, but I promise not to do this too often :P 18:26:02 <jillr> thanks for all your work on it gwmngilfen-work! 18:26:04 * gwmngilfen-work sends fireworks 🎆 18:26:05 <cidrblock[m]> thx Gwmngilfen for all the work you've done. exciting stuff 18:26:10 <felixfontein> dmsimard: abadger1999: do you want a quick discussion on the Ansible 5 schedule? 18:26:16 <dmsimard[m]> wow there's actual fireworks 18:26:19 <gwmngilfen-work> :D 18:26:37 <jillr> the fireworks show on irssi, and I kind of like them :) 18:26:49 <dmsimard> felixfontein: If there is nothing else to discuss, I created a placeholder topic https://github.com/ansible-community/community-topics/issues/37 18:26:54 <felixfontein> hmm I don't see them, but I have some trouble with unicode :) 18:27:07 <dmsimard> in element there were actual fireworks across the window, not just the emoji 18:27:09 <gwmngilfen-work> i'll stop being so exclusionary now :P 18:27:24 <abadger1999> Basically, slip final to 2021-11-30 to account for ansible-core slipping their final release by two weeks. 18:27:42 <gwmngilfen-work> i have to go put kids to bed, as usual at this time. thanks all. felixfontein do I need to update the topic? 18:27:53 <felixfontein> #topic Revise planned schedule for the release of Ansible 5 18:27:53 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/37 18:28:12 <felixfontein> gwmngilfen-work: if you find it wasn't updated by tomorrow, please do :) 18:28:14 <abadger1999> (I'm updating the schedule to slip other release dates, too... but that takes a little more work... I don't have it ready just yet) 18:28:17 <felixfontein> I'll try to do it afterwards 18:28:26 <gwmngilfen-work> perfect. later everyone! 18:28:36 <felixfontein> if someone has some specific comments on the schedule, add them now, or to the issue 18:28:56 <felixfontein> otherwise we can continue with 'Collection requirements: expanding the section on best practices', respectively talk about how we should proceed on that one 18:29:15 <felixfontein> (since I'm not sure we'll ever manage to finish that discussion ;) ) 18:29:39 <felixfontein> #topic Collection requirements: expanding the section on best practices 18:29:42 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/33 18:29:43 <dmsimard> I suggest we put a proposed update for the schedule together and formalize it at the next meeting 18:30:12 <felixfontein> dmsimard: sounds good! 18:30:21 <felixfontein> tadeboro just wrote a good summary on the discussion: #topic Collection requirements: expanding the section on best practices 18:30:23 <tadeboro> I promised a summary and I delivered it ... 5 seconds ago because I forgot to copy it from vim to GitHub ;) 18:30:25 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/33 18:30:29 <felixfontein> gna 18:30:31 <felixfontein> https://github.com/ansible-community/community-topics/issues/33#issuecomment-892878272 18:30:36 <felixfontein> copy'n'paste is hard... 18:30:54 <felixfontein> #info Current state of discussion https://github.com/ansible-community/community-topics/issues/33#issuecomment-892878272 18:32:43 <abadger1999> #action abadger1999 to put together an update to the ansible-5 schedule for next meeting 18:33:20 <dmsimard> do you have an example of a resource module ? 18:33:47 <felixfontein> on the current discussion, I'm not really familiar with resource modules (i.e. I never used any), so it's hard for me to really comment on the open question 2 (in tadeboro's summary) 18:33:56 <briantist> same 18:34:10 <cidrblock[m]> https://docs.ansible.com/ansible/latest/network/user_guide/network_resource_modules.html 18:34:10 <tadeboro> I would say that we should at least decide what to do with the networking-related resource modules since this decision impacts the inclusion process of trendmicro.deepsec 18:34:19 <abadger1999> dmsimard: https://github.com/ansible-collections/trendmicro.deepsec/blob/main/plugins/modules/deepsec_apikey.py 18:34:34 <cidrblock[m]> https://www.ansible.com/blog/getting-started-with-bgp-global-resource-modules 18:35:18 <felixfontein> tadeboro: since trendmicro.deepsec is not a network collection, but a security collection, how does solving the question for network help with it? 18:35:20 <dmsimard> ah, so "state: gathered" 18:36:17 <cidrblock[m]> the resource module pattern is in use in security as well, eg https://www.ansible.com/blog/deep-dive-on-cisco-asa-resource-modules 18:36:40 <jtanner> i feel as though that encourages people to do whatever they want with state, aside from present/absent. but that's a dead horse at this point 18:36:42 <tadeboro> felixfontein: For some reason, I had in my mind that that collection is part of networking. Do not ask me why. 18:37:04 <felixfontein> tadeboro: maybe it is also related to networking, but it looked more like security to me - at least on the first glance :) 18:37:33 <jillr> many security appliances function in a similar fashion to network appliances, so aiui the decision was to write many of them as resource modules 18:37:33 <cidrblock[m]> present/absent would have never worked for list or resources, encouraging off box SOT 18:37:41 <jillr> makes sense to me from that perspective 18:37:41 <felixfontein> #chair jtanner 18:37:41 <zodbot> Current chairs: abadger1999 acozine briantist cidrblock[m] cyberpear dericcrago dmsimard felixfontein geerlingguy gwmngilfen-work jillr jtanner samccann tadeboro 18:37:42 <cidrblock[m]> * present/absent would have never worked for list of resources, encouraging off box SOT 18:37:49 <tadeboro> I just saw people from networking working on it and I guess assumed this is part of the networking. 18:37:52 <jtanner> and that's fine ... 18:38:21 <cidrblock[m]> @jil 18:38:46 <jtanner> but if the state setting becomes it's own language for every module with no bounds on what the choices are ... it's not really a "state" anymore imo. 18:39:05 <cidrblock[m]> * jillr: yeah, security policy, ACL, sec ops not that different from networking in some areas 18:39:33 <abadger1999> I am +1 for network resource modules to follow the guidelines in https://docs.ansible.com/ansible/latest/network/user_guide/network_resource_modules.html . Probably should move them into the collection overview and have future changes to them be approved here. -1 for doing that elsewhere. 18:39:49 <jillr> if the state setting in those cases is consistent with the appliance/remote api/vendor standard/etc I think there's a good argument for deviating from ansible's standards 18:40:09 <felixfontein> I can see that managing (some?) security appliances is similar enough to managing network devices, but is that really everything that "security" does? resp. the only aspect of security that resource modules are used for? 18:40:22 <jillr> rather than trying to shoehorn something into our model that really doesn't intend to function that way 18:40:53 <abadger1999> "security appliance" could be defined perhaps and then network_resource_module could be scope changed to be "networked_appliance" or something. 18:40:53 <dmsimard> The doc that abadger1999 linked provides some of the potential values for state: merged, replaced, overridden, deleted, gathered, rendered and parsed (no present or absent?) 18:40:57 <cidrblock[m]> Maybe the question is, should the resource module pattern be one of 2 possible approaches for developing modules 18:41:11 <jillr> assuming there's a documented, "this device works in this way" and not just "I didn't feel like writing modules that way" 18:41:27 <abadger1999> jillr: I don't see how separating out something that's already separated is really shoehorning... just splitting. 18:41:37 <cidrblock[m]> # 1 being basic absent/present, #2 being resource mgmt (eg lists of resources etc) 18:41:43 <cidrblock[m]> * # 1 being basic absent/present, #2 being resource mgmt (eg lists of resources etc) 18:42:06 <abadger1999> I don't think anyone is proposing your #1 18:42:18 <cidrblock[m]> kk 18:42:23 <jtanner> *shrug* I shared my opinion but I know that people are gonna do whatever they want and justify it any way possible, so it doesn't really matter to me. Happy unbounded state definitioning to you all 18:42:38 <felixfontein> there are modules which configure stuff without having state=present and absent 18:42:40 <abadger1999> what's being proposed is that info and facts are returned via separate modules. 18:43:29 <cidrblock[m]> abadger1999: the network facts modules do that 18:43:30 <dmsimard> jtanner: thanks for participating and sharing your thoughts, it is not in vain :) 18:43:48 <abadger1999> a module could implement state=merged/deleted/overridden and still be okay. (they just can't combine with info and facts) 18:43:58 <cidrblock[m]> * abadger1999: the network facts modules do that (in addition to the gathered state in the resouce modules, gather_facts is another route) 18:43:59 <felixfontein> abadger1999: exactly 18:44:06 <abadger1999> *can't combine with things that belong in the territory of info and facts 18:44:47 <felixfontein> cidrblock[m]: so what's the advantage of using state=gathered over using a _info module? I think I still don't understand that :) 18:45:23 <cidrblock[m]> convenience more than anything. each resource module has a very specific scope, and the facts shape == the argspec 18:45:49 <cidrblock[m]> it's the 1 module to go round trip 18:46:00 <dmsimard> convenience for the user or for the developer ? 18:46:03 <dmsimard> (or both) 18:46:09 <cidrblock[m]> user 18:46:21 <abadger1999> facts shape can still == argspec in a separate module. 18:46:49 <abadger1999> which would let you continue to roundtrip data. 18:46:55 <cidrblock[m]> abadger1999: yes, but why the need for the 2x the modules? 18:47:09 <cidrblock[m]> and 2x the docstrings 18:47:29 <felixfontein> 2x the docstrings in RETURN is the only argument I can fully accept :) 18:47:37 <cidrblock[m]> in the playbook, it's very simple and intuitive........... eg ios_bgp => gathered 18:47:44 <sivel> the original discussion a while back, was largely around intent and definition of the `state` parameter 18:47:58 <felixfontein> there's some PR by bcoca which will allow to simplify this in the future, but it will take a long time until we can really use it everywhere 18:48:00 <sivel> since gathered doesn't fit in the definition of a resource state 18:48:05 <cidrblock[m]> the resource modules specify the doc string is the return value 18:48:41 <sivel> https://i.imgur.com/79s7WNk.gif 18:48:42 <cidrblock[m]> state was used to depict the state of the resource configuration 18:48:44 <felixfontein> but in the resource modules, I think you already have the repetition that the same data structure has to be documented both in DOCUMENTATION *and* RETURN 18:48:57 * sivel slinks back into the depths of his tormented mind 18:48:57 <cidrblock[m]> (not to suggest any operational state) 18:49:29 <abadger1999> sivel: Heh. I thought that was going to be a screenshot of previous discussion. 18:49:38 <sivel> haha 18:49:41 <abadger1999> You missed the opportunity to rickroll me ;-) 18:50:34 <cidrblock[m]> the resource module state can be ||'ed to HTTP methods....... where one endpoint supports GET, PUT, POST, PATCH, DELETE etc 18:50:43 <cidrblock[m]> (somewhat) 18:51:01 <felixfontein> hmm, is it normal that resource modules like https://github.com/ansible-collections/trendmicro.deepsec/blob/main/plugins/modules/deepsec_apikey.py do not document RETURN? 18:51:47 <dmsimard> it kind of does under examples 18:52:02 <cidrblock[m]> no..... that's a miss. It should be https://docs.ansible.com/ansible/latest/collections/cisco/ios/ios_interfaces_module.html#return-values 18:52:14 <cidrblock[m]> "The configuration returned will always be in the same format of the parameters above." 18:52:39 <abadger1999> it helps to separate out things that do not change state into modules with their own naming convention so that users can have some expectations about what the module will or won't do from the name. 18:53:08 <abadger1999> (answering what having two modules is god for) 18:53:37 <felixfontein> cidrblock[m]: that documentation doesn't mention how `before` and `after` look; I would expect that the documention at least says that the output format is exactly as the input format for `config` 18:54:09 <cidrblock[m]> It should "The configuration returned will always be in the same format of the parameters above." 18:54:31 <felixfontein> cidrblock[m]: ah, I overlooked the sample :) 18:54:59 <abadger1999> it can also be helpful for developers to do the right thing with for ansible features like check_mode where an info module should return the same values in check mode as normal mode whereas a conglomerate module might have to be skipped in check mode because of things it does in some of its state-changing actions 18:55:11 <cidrblock[m]> https://github.com/ansible-network/cli_rm_builder/blob/main/roles/scaffold_resource_module/templates/module_directory/network_os/network_os_resource.py.j2#L23 If the source for resource modules........ if that explanation is missing it's a miss 18:56:32 <cidrblock[m]> felixfontein: side note, the return value for resource modules is actually passed through the argspec on the way out.... 18:57:17 <felixfontein> cidrblock[m]: I think you already mentioned that last week - but that's not a reason why it needs to be in the same module :) (only if you want to avoid having the argspec in module_utils) :) 18:57:22 <cidrblock[m]> to guarantee the "before" payload can be used for a rollback 18:58:04 <felixfontein> cidrblock[m]: https://github.com/ansible-network/cli_rm_builder/blob/main/roles/scaffold_resource_module/templates/module_directory/network_os/network_os_resource.py.j2#L26 should be `when I(state) is C(merged), C(replaced), ...` 18:58:19 <felixfontein> I() is for options, C() for values 18:59:04 <cidrblock[m]> felixfontein: thx, will log an issue 18:59:10 <felixfontein> hmm, ok, we're almost out of time again 18:59:17 <felixfontein> and still not really closer to resolving this :) 18:59:23 <felixfontein> #topic open floor 19:00:13 <felixfontein> does anyone have something quick before we close? 19:00:17 <felixfontein> (i.e. in 1-2 minutes)? 19:00:27 <dmsimard> nothing from me 19:00:50 <jillr> nope, thanks felixfontein 19:01:33 <cidrblock[m]> thx all! 19:01:37 <felixfontein> #endmeeting