18:00:05 <felixfontein> #startmeeting Ansible Community Meeting
18:00:05 <zodbot> Meeting started Wed Jul 28 18:00:05 2021 UTC.
18:00:05 <zodbot> This meeting is logged and archived in a public location.
18:00:05 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:05 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:05 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:05 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
18:00:05 <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:06 <andersson007_> i'm not here, have a nice meeting folks:)
18:00:09 <dmsimard> o/
18:00:09 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics
18:00:12 <felixfontein> #topic Updates
18:00:17 <felixfontein> #chair dmsimard gwmngilfen
18:00:17 <zodbot> Current chairs: dmsimard felixfontein gwmngilfen
18:00:21 * dericcrago waves
18:00:21 <gundalow> o/
18:00:24 <jillr> o/
18:00:25 <cidrblock[m]> hello all
18:00:28 <felixfontein> #chair dericcrago gundalow jillr cidrblock[m]
18:00:28 <zodbot> Current chairs: cidrblock[m] dericcrago dmsimard felixfontein gundalow gwmngilfen jillr
18:00:28 * jtanner yawns
18:00:34 <felixfontein> #chair jtanner
18:00:34 <zodbot> Current chairs: cidrblock[m] dericcrago dmsimard felixfontein gundalow gwmngilfen jillr jtanner
18:00:43 <gwmngilfen> o/
18:00:46 <abadger1999> Bom día
18:00:59 * lmodemal Unable to attend. I have a conflict at this time :(
18:01:03 <felixfontein> #chair abadger1999
18:01:03 <zodbot> Current chairs: abadger1999 cidrblock[m] dericcrago dmsimard felixfontein gundalow gwmngilfen jillr jtanner
18:01:07 <tadeboro> o/
18:01:11 * gwmngilfen switches to desktop
18:01:25 <felixfontein> #chair tadeboro
18:01:25 <zodbot> Current chairs: abadger1999 cidrblock[m] dericcrago dmsimard felixfontein gundalow gwmngilfen jillr jtanner tadeboro
18:01:39 <dmsimard> #info Ansiblefest CFP responses have allegedly started going out, saw a mention of a Zuul talk being accepted
18:02:01 <felixfontein> CFP = call for papers
18:02:25 <dmsimard> #info The release of ansible-core 2.12 is being slightly delayed, details in the roadmap update: https://github.com/ansible/ansible/pull/75350
18:02:26 <github-linkbot> https://github.com/ansible/ansible/pull/75350 | open, created 2021-07-28T16:52:54Z by sivel: Update 2.12 roadmap for schedule change [affects_2.12,core_review,docs,docs_only,needs_triage,support:core] 
18:02:41 <samccann> o/
18:02:46 <acozine> o/
18:02:48 <dmsimard> ^ we'll need to review the roadmap we have for the ansible community package
18:03:15 <cyberpear> oþ
18:03:18 <felixfontein> #chair samccann acozine cyberpear
18:03:18 <zodbot> Current chairs: abadger1999 acozine cidrblock[m] cyberpear dericcrago dmsimard felixfontein gundalow gwmngilfen jillr jtanner samccann tadeboro
18:03:20 <cyberpear> o/
18:03:23 <dmsimard> for posterity, roadmap for ansible 5: https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/COLLECTIONS_5.rst
18:03:54 <felixfontein> thanks for the roadmap update!
18:03:59 <briantist> o/
18:04:07 <dmsimard> any other updates before we move on to the next topic ?
18:04:07 <sivel> We've only delayed 2 weeks, but added 4 weeks to the last dev cycle
18:04:17 <felixfontein> #chair briantist
18:04:17 <zodbot> Current chairs: abadger1999 acozine briantist cidrblock[m] cyberpear dericcrago dmsimard felixfontein gundalow gwmngilfen jillr jtanner samccann tadeboro
18:04:30 <felixfontein> (sivel: do you want to be chaired as well?)
18:04:37 <sivel> I'm a table
18:04:49 <sivel> no need to chair me
18:04:51 * felixfontein puts a plate on top of sivel
18:05:11 * acozine adds a wine glass
18:05:21 <gwmngilfen-work> now i want to go out for dinner
18:05:45 <felixfontein> no need to go out, we have chairs and table here :)
18:05:54 <felixfontein> are there any more updates?
18:06:08 <dmsimard> none for me
18:06:16 <felixfontein> ok, then let's start:
18:06:16 <felixfontein> #topic Proposal: Ansible Community to accept Matrix as an equal partner to IRC (pre-discussion)
18:06:19 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/36
18:06:23 <felixfontein> gwmngilfen-work: do you want to say a few words?
18:06:30 <gwmngilfen-work> sure
18:06:55 <gwmngilfen-work> I'm mainly wanting to give people a heads up, as I've done a fair bit of research and talking 1:1 with folks
18:07:13 <gwmngilfen-work> so, there's a lot to read if folks wish to do so, and thats not fair to drop on you in a single meeting
18:07:48 <gwmngilfen-work> i also have scheduled a test of what I hope the Contributor Summit will look like, and we can use that for a more interactive Q&A on Tuesday
18:08:02 <gwmngilfen-work> (it's more for the test, but the Q&A is useful too)
18:08:31 <gwmngilfen-work> I thought a week to digest / ask concerns would be about right, and I'll raise it again next week
18:09:03 <gwmngilfen-work> so unless folks have something specific, I think that's all I have to say at this stage
18:09:26 <dmsimard> gwmngilfen-work: I just wanna say thanks for driving most of the work behind the initiative
18:09:27 <felixfontein> I'm looking forward to that Q&A - it will have video 'inside' matrix, right?
18:09:32 <acozine> does anyone here today have objections to matrix?
18:09:40 <gwmngilfen-work> #info Q&A Tuesday 3pm UK time - chat here and video at https://youtu.be/9R31zq_7R6c
18:09:55 <felixfontein> what's 3pm UK time in UTC?
18:09:55 <gwmngilfen-work> I do have a 1:1 with jillr later today to talk about accessibility too
18:10:02 <gwmngilfen-work> mmm, 2pm?
18:10:18 <gwmngilfen-work> the stream page should localise it, I think
18:10:33 <briantist> I have no specific objections to matrix but I have no intention of using it at the moment
18:10:42 <gwmngilfen-work> users on Element should be able to watch it here, but anyone can watch with that link
18:10:47 <felixfontein> does the video only works with youtube, or also in matrix?
18:10:48 <gwmngilfen-work> briantist: 100% fine by me
18:10:53 <felixfontein> ah
18:11:02 <gwmngilfen-work> felixfontein: i'm just going to embed the YT stream here
18:11:03 <briantist> if there's a compelling advantage I might try it but for now IRC via irccloud is working for me
18:11:32 <sivel> briantist: yeah, same here, sticking with IRC for life ;)
18:11:32 <abadger1999> Will gwmngilfen-work: Since felix is the second person to ask, should we have a test session with video inside of matrix at some point too?
18:11:37 <briantist> but it's great that there's an alternative; a peer service seems like a good idea :)
18:11:54 <gwmngilfen-work> we can do that
18:12:02 <felixfontein> youtube is kind of cheating :)
18:12:11 <briantist> sivel: in truth, I hadn't used IRC in like 15 to 20 years until I started getting involved with Ansible 😅
18:12:21 <gwmngilfen-work> it's just bluejeans primetime, basically - presenter links and viewer links
18:12:36 <tadeboro> I did test it and as an irccloud user I found things are not that different. And if community members can get backlog "for free", I am all for it.
18:12:37 <acozine> that's how I feel now (i'll stick with IRC), but I do remember the first time I tried to join an IRC channel (back maybe 10 years ago) how high of a bar it felt like at the time
18:12:41 <gwmngilfen-work> briantist: one of my design goals is to keep IRC on par, so you're good :)
18:13:02 <abadger1999> felixfontein: Two different audiences, I think.  YT is probably what we'd do  for conferences (lecture-style content).  Embedded seems better for group meetings and discussions.
18:13:19 <gwmngilfen-work> I've been using Matrix as my IRC bouncer for at least 4 years, so I may be a bit biased, but I'm trying to be open :P
18:13:30 <abadger1999> I suppose there are some conference sessions that would be better as discussion-style too.
18:13:38 <gwmngilfen-work> abadger1999: felixfontein the embedded Jitsi can work too, but scalablity means I wouldn't push it over 20
18:13:54 <gwmngilfen-work> I heard Element.io do all-company calls (60+ people) but it struggles :)
18:14:15 <acozine> so I'm +1 on the matrix plan, but I want to be sure that objections get considered, discussed, etc.
18:14:17 <felixfontein> hmm, so there's no real replacement for google hangouts (or whatever else) yet?
18:14:20 <gwmngilfen-work> and, to be clear for IRC folks, even the embedded Jitsi can be joined from a standalone browser
18:14:29 <felixfontein> (for things like contributor summit when there are a lot more people around)
18:14:45 <gwmngilfen-work> i'd be happy to schedule a test of what the Jitsi hos I'm using can scale to as well
18:15:07 <gwmngilfen-work> for CS I'm planning the primetime style of presenter/viewer, since the videos end up on YT anyway
18:15:39 <gwmngilfen-work> we get higher attendance when its the Fest CS anyway, so we have to do something different - didn't we use primetime last year?
18:15:41 <felixfontein> which means an intro round, or voice questions by random viewers, don't work?
18:15:59 <felixfontein> (I have no idea what primetime is)
18:16:21 <gwmngilfen-work> bluejeans primetime is their "big audience" offering
18:16:40 <felixfontein> ah. I only know bluejeans :)
18:16:52 <tadeboro> Bluejeans primetime is (yet another) Zoom/Teams/PutYourOwnStuffHere ;)
18:16:55 <gwmngilfen-work> intros, no (unless you count in here, since the chat is persistent it's nice to meet people at any time)
18:17:19 <gwmngilfen-work> voice questions, well, I'd open to inviting people onto the presenter link to speak :)
18:17:26 <gwmngilfen-work> *I'd be
18:17:43 <gwmngilfen-work> to turn the question back on itself, here's what I'm trying to avoid
18:17:51 <felixfontein> :)
18:18:04 <felixfontein> ok, so everyone now can think about this, and we discuss it again in a week?
18:18:14 <gwmngilfen-work> putting a link to an open conference in here, with (according to Matrix) 200 people in the room, and having no idea how many will click "join" :)
18:18:46 <gwmngilfen-work> hence the presenter style
18:18:54 <gwmngilfen-work> but I'm open to lots of testing
18:19:27 <gwmngilfen-work> #info matrix - we should try to scale test the in-room video options
18:19:41 <felixfontein> :+1:
18:19:57 <gwmngilfen-work> any more questions? I'll be piling these up for the stream on Tue so I have material :P
18:20:12 <gwmngilfen-work> if anyone has any later, feel free to DM me and I'll answer (and add to the pile)
18:20:18 <gundalow> Video intros is something we can look at improving in the future
18:20:38 <gwmngilfen-work> breakouts is where i see the in-room stuff going well
18:21:07 <gundalow> I believe the proposed setup will have feature parity (and them some) for the previous Contributor Summits where we used Primetime
18:21:08 <gwmngilfen-work> ok, next itme then?
18:21:14 <gwmngilfen-work> *item
18:21:35 <gwmngilfen-work> gundalow: assume I can find a working pollbot (thanks dmsimard :P)
18:21:42 <gundalow> ah, yup
18:21:54 <gundalow> I'm sure you can find some oldskool Perl
18:22:07 <cyberpear> my biggest concern about matrix would be the messages that look on the IRC side like "so-and-so sent a long message: http://link-to-read-message"
18:22:47 <felixfontein> that's one of the more annoying aspects
18:22:51 <gwmngilfen-work> so, i think the length at which that happens is tunable, but is that better or worse than Libera's ircds truncating messages?
18:22:59 <felixfontein> (next to the spam caused by corrections)
18:23:17 <gwmngilfen-work> i do plan to write some docs around etiquette, for sure, and reply editing is on that list
18:23:18 <gundalow> I believe there is a PR in flight to disable corrections
18:23:42 <gwmngilfen-work> i don't believe disabling it entirely is right. you will have two versions of history
18:24:13 <felixfontein> depends on whether disabling is done on matrix side, or by the bridge
18:24:22 <gwmngilfen-work> but I do believe we can educate people about repeat edits on a single line, which is the major irritation
18:24:25 <gundalow> oh, I thought it blocked it on the Matrix side. I maybe miss remembering
18:24:31 <gundalow> yup, education is a solid option
18:24:38 <felixfontein> +1
18:24:45 <gwmngilfen-work> to be fair, i'm not aware of the details, perhaps it's a per-room thing
18:24:54 <felixfontein> ok, it's 18:24 UTC already, let's switch to another topic soon
18:25:00 <gwmngilfen-work> its not like IRC doesnt have etiquette too
18:25:05 <gwmngilfen-work> so we can teach.
18:25:06 <abadger1999> Several things would be best done on the client side but we can't push those to clients (unless the protocol supported saying what features are allowed in rooms?)
18:25:07 <gwmngilfen-work> sure lets move on
18:25:31 <felixfontein> #topic Collection requirements: expanding the section on best practices
18:25:34 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/33
18:25:56 <felixfontein> tadeboro created this issue in response to a collection review
18:26:53 <tadeboro> Yep. While revieving one of the network collections, I learned that resource modules have their own best practices that contradict current best practices for regular modules.
18:27:00 <felixfontein> it looks like resource modules (as defined by the network team?) do not fit to the guidelines we currently have for modules, namely that things like state=get should be avoided and _info/_facts modules should be added instead
18:28:08 <gundalow> I'd really like to rewrite off of those docs (best practices, checklist, etc)
18:28:08 <tadeboro> I assumed the deviation was done with a good reason by people that know better than me, so it feel wrong to mark such collections as non-conforming.
18:28:14 <acozine> are we talking about https://docs.ansible.com/ansible/latest/user_guide/playbooks_best_practices.html?
18:28:16 <cidrblock[m]> One reason I am ok with the way network resource modules work (eg state=gathered) is that the request and return values are 1:1, even the return value is passed through the argpsec before being returned to the user
18:28:59 <tadeboro> acozine: https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#development-conventions is what triggered this discussion.
18:29:07 <acozine> or or https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_best_practices.html#developing-modules-best-practices?
18:29:11 <cidrblock[m]> In the case the shape of the return != the argpsec, I would agree a fact or info module may be a better choice
18:30:17 <abadger1999> I don't think we'd want more of this type of contradictory best practices in the future.
18:30:22 <felixfontein> cidrblock[m]: I'm not sure I follow the argument that because return == argspec, state=gathered is ok. why not have another _info module which returns exactly the same, as in all other cases?
18:31:10 <acozine> tadeboro: ah, okay, thanks
18:31:41 <cidrblock[m]> felixfontein: The goal of a resource module is to provide complete configuration management of a given network resource.  This includes the transformation of the current native configuration bidirectionally to/from structured data.
18:32:48 <abadger1999> yeah, I agree with felixfontein's "does X really follow from Y".
18:32:52 <cidrblock[m]> The resource modules always return a before and after payload which == the argspec, the contact with the user is for 100% idempotent round trip cfg mgmt
18:32:57 <felixfontein> cidrblock[m]: I understand that, but I don't see why this makes it necessary to have one module for gathering and modification
18:33:34 <abadger1999> cidrblock[m]: I think the thing you need to justify is the first part, that a resource module should be a complete  solution.
18:34:17 <cidrblock[m]> felixfontein: The same information is exposed through the facts subsystem as well via gather facts and/or the platform specific facts module.
18:34:50 <cidrblock[m]> The feedback early on was........ why 2 different plugins for the same resource?
18:34:54 <felixfontein> or maybe a related question: why do we have the guideline that state=get should be disallowed, and we should have a _info/_facts module instead? and why does this reasoning no longer applies to resource modules?
18:35:40 <abadger1999> sivel: ^
18:36:04 <sivel> felixfontein: `get` isn't a state
18:36:29 <sivel> at least that is what we decided previously.  state=get/list/whatever was disallowed when core was responsible for approval
18:36:41 <felixfontein> (I don't know where the rule came from... my assumption was always that it simplifies the module's UX, since you don't have so many conditional requires, and that supports_check_mode=False doesn't work well with state=get)
18:37:02 <sivel> Yeah, it was always `get` isn't a resource state, it's an action
18:37:11 <sivel> so it should be a _facts or _info module instead
18:37:16 <cidrblock[m]> I think we may need to differentiate operation state/activity from configuration management here....  focusing on cfg mgmt, If a plugin is well scoped, idempotent and guarentees round trip....  I don't see why that plugin should not provide the current configuration.  I personally find is less confusing than jumping between 2 different plugins
18:37:17 <felixfontein> sivel: I would assume that `gathered` isn't a state either, then?
18:37:35 <sivel> correct
18:38:04 <tadeboro> Just for reference: resource modules define the following "states": https://docs.ansible.com/ansible/latest/network/user_guide/network_resource_modules.html#network-resource-module-states
18:38:20 <cidrblock[m]> in the case of resource modules, the state tried to represent the state of the configuration after module completeion
18:38:43 <briantist> cidrblock[m]: I tend to agree; I can understand why it sometimes makes sense to have separate facts/info modules, but other times it's a pain. I think the strong stance on it is a little much, but I guess it's also much harder to have nuance in a large community
18:38:53 <abadger1999> check-mode would seem to be a good reason unless resource modules do support check mode?
18:39:19 <cidrblock[m]> all the network resourc emodules support check mode
18:39:21 <felixfontein> abadger1999: as far as I understand resource modules, I think they need to be able to support check mode to be proper resource modules anyway
18:39:39 <briantist> abadger1999: true, though imo a module that doesn't support check mode is incomplete ;)
18:39:49 <sivel> yeah, the last 3, gathered, rendered, parsed, aren't what we would have historically allowed as states. They would have existed in a separate _info module, with some form of "type" argument instead
18:39:50 <abadger1999> briantist: In an ideal world.... ;-)
18:40:05 <felixfontein> briantist: with some APIs, implementing check mode is really hard or even impossible :)
18:40:06 <briantist> I can dream... 💭
18:40:25 <cidrblock[m]> to further complicate things, the network resource modules also support rendered and parsed, which are off box activities for speculative changes and data transformation
18:40:26 <sivel> get me info, vs ensure the state of a resource
18:40:28 <briantist> felixfontein: yeah I can understand that; exceptions exist
18:41:06 <sivel> I think that's the basis of how we historically have looked at it: get me info, vs ensure the state of a resource
18:41:12 <sivel> 2 types of modules for those scenarios
18:41:33 <briantist> 3 types with facts/info...
18:41:51 * briantist resists the offtopic urge to complain about info vs facts
18:42:06 <felixfontein> :)
18:42:33 <cidrblock[m]> I find multiple modules to retrieve, parse, template, configure the same resource more confusing than a single module that cna perfom and retrieve 100% declaritive cfg mgmt
18:42:33 <tadeboro> This is how I see modules also. And 99% of the time, I do not care about the _info modules because what I care about is enforing an end state that I defined, no matter what the current state is.
18:42:38 <felixfontein> cidrblock[m]: that definitely complicates things a lot :)
18:42:50 <cidrblock[m]> @fe
18:43:08 <cidrblock[m]> * felixfontein: just trying to be all upfront here :)
18:43:38 <sivel> we also aren't really declarative cfg management for that matter either :)
18:44:05 <cidrblock[m]> Is there an appetite to define a "basic" module vs. a "resource" module? and provide guidelines for each
18:44:11 <cidrblock[m]> * Is there an appetite to define a "basic" module vs. a "resource" module? and provide guidelines for each?
18:44:13 <felixfontein> I'm tending to propose that we should keep the current guidelines, and augment them with "you can only deviate from these guidelines if you implement network resource modules as defined here: <LINK>"
18:44:29 <abadger1999> felixfontein: <nod>
18:44:35 <sivel> I'd still argue that the network resource module states are wrong
18:44:44 <abadger1999> Are there a lot of network resource modules in the wild today?  (I assume yes)
18:44:59 <abadger1999> cidrblock[m]: ^
18:45:01 <cidrblock[m]> sivel: Network resource modules, esp "overridden" do declarative cfg mgmt
18:45:08 <felixfontein> sivel: true, but I think that train already left quite some time ago... (since I also assume yes to abadger1999's question)
18:45:41 <felixfontein> hi resmo!
18:45:54 <cidrblock[m]> yes, there are quite a few now, the ones written by the network team as well as others (partner, community)  as well as resource module scaffolding tool
18:46:15 <cidrblock[m]> * yes, there are quite a few now, the ones written by the network team as well as others (partner, community)  as well as a resource module scaffolding tool
18:46:15 <sivel> ultimately ansible is an orchestration tool, that can produce results similar to cfg mgmt
18:46:33 <abadger1999> <nod>  So given that, I think I'm basically with felix.  However, I think we should take some steps to not be put in this situation in the future.
18:47:03 <sivel> I was doing something before the ping...
18:47:04 <cidrblock[m]> We should no limit resource modules to just network....  the pattern can be found in the security space as well
18:47:07 <sivel> oh, cleaning my glasses
18:47:10 <acozine> heh
18:47:12 <cidrblock[m]> * We should not limit resource modules to just network....  the pattern can be found in the security space as well
18:47:31 <tadeboro> When I read the resource module docs, I did not like them. But I tried to keep an open mind since, as I said before, I assumed people have good reasons for designing the API the way it is now.
18:47:34 <felixfontein> maybe resource modules should have been discussed in ansible/proposals first before they were introduced
18:47:44 <abadger1999> cidrblock[m]: I would say no to the pattern inthe security space.
18:48:00 <cidrblock[m]> abadger1999:
18:48:04 <cidrblock[m]> * abadger1999:It already exists
18:48:14 <abadger1999> networking is kind of in its own world (no one else makes use of httpapi or cliconf plugins for example) so I feel okay about carving an exception for them based on both that and they already exist en masse.
18:48:41 <sivel> yeah, I think if much of networking went through proposals, it would look completely different than it does
18:48:44 <abadger1999> But security tools are things that general sysadmins are going to be using so I don't think they should differ from the other modules which are general sysadmin tools.
18:49:03 <cidrblock[m]> (soap box)  The resource modules are some of the most complete modules we have wrt cfg mgmt.  I think we should encourage the pattern
18:50:31 <abadger1999> OTOH, the resource modules are some of the least ansible-ish modules we have, so we should discourage the pattern.
18:50:33 <tadeboro> Most of the modules our team writes are resource modules in spirit, but we still keep _info part separate because _info modules are not used that often. And they are just a few lines of code, so not much maintenance burden here.
18:50:35 <jillr> non-cyb-clock chimes: 50 minutes into the meeting; 25 minutes on the topic of expanding the section on best practices
18:51:02 <felixfontein> tadeboro: same here
18:51:04 <sivel> I'm mostly with abadger1999 here. Much of networking has happened off in a silo, and while their patterns are expanding, somewhat largely due to the relation of security and networking, I'd be hesitant, to just accept those patterns, without larger discussion
18:51:12 <abadger1999> I'm not sure that the stated goals (be ansible-ish and complete) are mutually exclusive, either.
18:51:16 <sivel> ...due to the fact that networking has diverged so much from everything else
18:51:21 <cidrblock[m]> It seems to me we have 2 patterns here, basic (module + info/fact) and resource (full round trip, guarentted idemopotent)
18:51:37 <cidrblock[m]> @ab
18:51:48 <tadeboro> For example, all Sensu Go and ServiceNow modules operate as `state: merged` by default.
18:51:56 <cidrblock[m]> * abadger1999: agree, didn't mean to suggest that at all
18:52:50 <felixfontein> ok, so right now we have a mess with no easy time out, and we're running out of time for this meeting
18:52:56 <felixfontein> s/time/way :)
18:52:58 <abadger1999> <nod>
18:53:17 <felixfontein> (the first one... IRC corrections are hard :D )
18:53:31 <abadger1999> I would propose a narrow exception for network resource modules, possibly explicitly saying this doe not apply to any other modules.
18:53:32 <jtanner> why is a "regular module" not capable of guaranteed idempotency, aside from bad choices by the author(s)?
18:53:33 <cidrblock[m]> felixfontein: we can revisit, but I would like to continue at a later date. there is value in the RM approach and it has been well received
18:53:39 <abadger1999> I think that might pass
18:54:07 <tadeboro> I will try to summarize current discussion in a ticket. I invite you all to add your feedback in https://github.com/ansible-community/community-topics/issues/33
18:54:19 <felixfontein> jtanner: I think there is no reason except bad choices (or different design philosophies)
18:54:24 <cidrblock[m]> abadger1999: The pattern does not only apply to network and is already in use else where.  Properly executed, this should not be limited to network imo
18:54:32 <felixfontein> tadeboro: thanks a lot!
18:55:03 <felixfontein> ok, let's continue in that issue for now. we should revisit this in a meeting, maybe next week or the week after?
18:55:19 <cidrblock[m]> good 4 me
18:55:26 <felixfontein> (I sometimes get the feeling we have more topics than time to talk about them :D )
18:55:48 <abadger1999> <nod> ledt me info three things I think we should vote on (either together or separate)
18:55:49 <felixfontein> #topic open floor
18:55:54 <cidrblock[m]> felixfontein: I can think of worse problems to have :)
18:55:55 <felixfontein> #undo
18:55:55 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f4734483190>
18:56:00 <abadger1999> (But I'd like more time to think on my vote too)
18:56:12 <felixfontein> abadger1999: please go ahead and #info them
18:56:40 <felixfontein> cidrblock[m]: we have some topics from months ago we couldn't discuss so far, since there were always more pressing topics
18:57:03 <abadger1999> #info Future vote topic: Network resource modules do not have to follow the guideline for keeping _info and _facts in separate modules separate from the state establishing modules
18:57:09 <jtanner> perhaps yall should admit that these meetings are really only timed to make votes and move all the discussion to the tickets
18:57:11 <cidrblock[m]> Can I open floor this https://github.com/ansible-community/community-topics/issues/35 or should we schedule?
18:57:13 <abadger1999> #info Future vote topic: the .  Network resource modules must follow the guidelines for that type of module https://docs.ansible.com/ansible/latest/network/user_guide/network_resource_modules.html#network-resource-module-states
18:57:18 <felixfontein> cidrblock[m]: like 'new content for community.general?' and 'should we have a collection linter?'
18:57:42 <abadger1999> #info Future vote topic: No other modules are allowed to ignore the guidelines for keeping _info and _facts separate
18:57:44 <gundalow> jtanner: One of the aims of having https://github.com/ansible-community/community-topics/issues/ was to allow async discussion
18:57:57 <felixfontein> cidrblock[m]: you can present a few comments on it, but we don't really have time to discuss it today
18:58:05 <jtanner> yeah, perhaps it's time to cut over to async only
18:58:05 <abadger1999> We should probably info sivel's explanation of why the separation exists too
18:58:25 <felixfontein> jtanner: I'm more and more agreeing to that :)
18:58:44 <cidrblock[m]> felixfontein: ok, I would just ask people have a look, the work is being planned but I didn't want to miss the chance to engage here early on
18:58:45 <gundalow> jtanner: possibly. ompragash is looking at improving async discussion  as part of the Steering Committee work
18:58:59 <felixfontein> #topic open floor
18:59:01 <gundalow> s/possibly. /
18:59:05 <tadeboro> abadger1999: I will add that to the summary in the issue so it does not get lost.
18:59:09 <felixfontein> ok, let's have a one-minute open floor :)
18:59:12 <felixfontein> cidrblock[m]: ^
18:59:21 <gundalow> I'm off for the next two weeks, back on Monday 16th
18:59:29 <cidrblock[m]> It can wait
18:59:34 <abadger1999> tadeborothanks
18:59:36 <tadeboro> Yeah, currently we are failing at having an async discussions ;)
18:59:42 <felixfontein> yes :)
19:00:18 <abadger1999> Heh.  I think that discussion by its nature is better suited to the meetings and voting is better suited to the tickets.  Unfortunately, that is less helpful for time.
19:00:52 <felixfontein> true...
19:01:18 <felixfontein> #endmeeting