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