18:00:23 <felixfontein> #startmeeting Ansible Community Meeting
18:00:23 <zodbot> Meeting started Wed Apr 28 18:00:23 2021 UTC.
18:00:23 <zodbot> This meeting is logged and archived in a public location.
18:00:23 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:23 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:23 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
18:00:23 <felixfontein> abadger1999 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro: ping!
18:00:27 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/539 / Topics: https://github.com/ansible-community/community-topics
18:00:33 <tadeboro> o/
18:00:35 <jillr> o/
18:00:35 <dmsimard> \o
18:00:37 <cybette> o/
18:00:38 <andersson007_> o/
18:00:41 <felixfontein> #chair tadeboro jillr dmsimard cybette andersson007_
18:00:41 <zodbot> Current chairs: andersson007_ cybette dmsimard felixfontein jillr tadeboro
18:01:35 <samccann> \o
18:01:36 <briantist> o/
18:01:44 <felixfontein> #chair samccann briantist
18:01:44 <zodbot> Current chairs: andersson007_ briantist cybette dmsimard felixfontein jillr samccann tadeboro
18:02:31 <felixfontein> #topic Updates
18:02:31 <felixfontein> #info ansible-core 2.11.0 has been released
18:02:31 <felixfontein> #info community.general and community.network 3.0.0 have been released
18:02:34 <felixfontein> #info today we will decide which new collections will be included in Ansible 4
18:03:11 <cybette> #info Please register for Ansible Contributor Summit 2021.06 https://www.eventbrite.com/e/ansible-contributor-summit-202106-registration-152686374055?aff=irc
18:03:19 * dericcrago waves
18:03:24 <felixfontein> #chair dericcrago
18:03:24 <zodbot> Current chairs: andersson007_ briantist cybette dericcrago dmsimard felixfontein jillr samccann tadeboro
18:03:26 <cybette> I'm probably not up to clock duty today, just did 9 hours of booth duty at red hat summit.
18:04:02 <felixfontein> cybette: wow, then better get some rest :)
18:04:24 <cybette> thanks, planning on it :)
18:04:27 <samccann> I can attempt clock duty. cyb-clock-clone
18:04:28 <acozine> o/
18:04:39 <cybette> samccann: thanks!
18:04:44 <felixfontein> #chair acozine
18:04:44 <zodbot> Current chairs: acozine andersson007_ briantist cybette dericcrago dmsimard felixfontein jillr samccann tadeboro
18:05:41 <felixfontein> today we'll go through all collection inclusion applications, I hope it won't take too long :)
18:06:18 <felixfontein> I'll go through the collections in the tadeboro's order (https://github.com/ansible-community/community-topics/issues/10), I've already prepared a list of things to copy'n'paste
18:07:12 * gundalow waves
18:07:19 <felixfontein> #chair gundalow
18:07:19 <zodbot> Current chairs: acozine andersson007_ briantist cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
18:08:04 <abadger1999> Hello :-)
18:08:08 <felixfontein> #chair abadger1999
18:08:08 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
18:08:38 <felixfontein> does anyone know if more steering committee members will show up soon?
18:09:21 <abadger1999> I do not know.
18:09:29 <samccann> do you have a list you can ping here and see if that garners attention?
18:09:41 <dmsimard> we're missing cyberpear and jillr I think
18:09:46 <felixfontein> jillr is around
18:09:46 <dmsimard> no wait, jillr is here
18:10:00 <jillr> hola  :)
18:10:16 <andersson007_> привет:)
18:10:17 * tadeboro needs to find a list of members before anything else can happen ;)
18:10:20 <cyberpear> sorry I'm late
18:10:22 <abadger1999> cidrblock
18:10:29 <felixfontein> #chair cyberpear
18:10:29 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
18:10:35 <felixfontein> that's the nick I'm always forgetting...
18:10:36 <samccann> cyb-clock-clone sez we are 10 min into the meeting, 1 min into the jillr version of Where's Waldo ;-)
18:11:03 <acozine> heh
18:11:09 <felixfontein> well, let's start :)
18:11:09 <felixfontein> #topic Inclusion of dellemc.enterprise_sonic in Ansible 4
18:11:09 <felixfontein> #info Discussion: https://github.com/ansible-collections/ansible-inclusion/discussions/14
18:11:12 <felixfontein> #info Galaxy: https://galaxy.ansible.com/dellemc/enterprise_sonic
18:11:15 <felixfontein> #info Repository: https://github.com/ansible-collections/dellemc.enterprise_sonic
18:11:48 <jillr> samccann: hey I've been here!  hehe
18:12:42 <dmsimard> I have no personally reviewed that one but going from the comments of trusted reviewers it looks like it is good to go ? Are there any objections ?
18:13:07 <andersson007_> +1 to include it
18:13:08 <jillr> I'm +1
18:13:12 <felixfontein> I haven't reviewed it in detail, but the things I've looked at look good
18:13:30 <felixfontein> +1 for inclusion
18:13:31 <acozine> they've been responsive, +1
18:13:32 <tadeboro> I did review it. The maintainers are really responsive, so +1
18:13:54 <andersson007_> +1 to the maintainer
18:14:00 <abadger1999> I haven't reviewed any of the collections this time around :-/  I'm +0 on all of them unless you want me to look more closely now :-)
18:14:32 <abadger1999> (/me likes the comments about being responsive.  That's highly important :-)
18:14:46 <felixfontein> I've taken tadeboro's order, so we're starting with the ones that have good reviews. there will be problematic ones at the end :)
18:15:08 <felixfontein> should we start a formal vote, or is there anything people want to discuss before?
18:15:17 <felixfontein> (so far nobody said anything negative)
18:15:49 <gundalow> I agree with following tadeboro order on the summary issue
18:15:58 <samccann> this item isn't used in the sample playbooks in the readme (not a showstopper, just pointing it out) - documentation, examples, and return use FQCNs for M(..), examples, and seealso subsections
18:15:58 <samccann> Comment: MUST be fixed: see the comment above
18:16:20 <samccann> they are using the `collection` keyword instead there.
18:16:57 <andersson007_> i think FQCNs were fixed
18:17:05 <andersson007_> i checked recently
18:17:24 <felixfontein> andersson007_: except in README.md :)
18:17:31 <tadeboro> samccann: I did not look at the readme since that file is not used to render docs.
18:17:33 <samccann> yep see here - https://github.com/ansible-collections/dellemc.enterprise_sonic#sample-playbooks
18:17:50 <samccann> yeah, not sure if that FQCN rule applies to the readme or not
18:18:06 <dmsimard> wouldn't block over that
18:18:15 <felixfontein> me neither, they are also quick at fixing things
18:18:17 <andersson007_> i think it's not a blocker
18:18:31 <tadeboro> And I think that checkbox was designed for the built-in module docs, we did not think about readme at all when we wrote the checklist ;)
18:18:40 <samccann> heh
18:18:43 <jillr> it would be good to update but I also wouldn't block
18:18:43 <acozine> https://github.com/ansible-collections/dellemc.enterprise_sonic/pull/40/files#diff-7e2bc7b3c5e91a432241bc4d03252b86627b0415d8eed653ec786fd469116228R128 updated at least some of them
18:19:07 <acozine> not a blocker in any case
18:19:12 <samccann> should I open an issue to say 'please use FQCN in your readme examples?
18:19:19 <andersson007_> +1
18:19:19 <felixfontein> samccann: sounds good :)
18:19:30 <acozine> sure, or even a PR
18:19:33 <abadger1999> +1 to not blocking
18:19:40 <acozine> probably almost as quick to just fix it
18:19:43 <felixfontein> VOTE: should we include dellemc.enterprise_sonic in Ansible 4?
18:19:48 <andersson007_> +1
18:19:49 <tadeboro> +1
18:19:49 <acozine> +1
18:19:54 <felixfontein> +1
18:20:08 <dmsimard> +1 (though not steering committee member)
18:20:28 <jillr> +1
18:21:07 <felixfontein> #chair
18:21:07 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
18:21:09 <cyberpear> +1, but naming is still strange to me
18:21:26 <samccann> +1 (again not steering, just in passenger section)
18:21:32 <abadger1999> +1
18:22:03 <gundalow> +1
18:22:06 <samccann> cyb-clock-clone sez we are 21 minutes into the meeting, 10 min into the current collection review
18:22:16 <felixfontein> #agreed dellemc.enterprise_sonic will be included in Ansible 4
18:22:17 <felixfontein> great :)
18:22:24 <felixfontein> #topic Inclusion of hpe.nimble in Ansible 4
18:22:24 <felixfontein> #info Discussion: https://github.com/ansible-collections/ansible-inclusion/discussions/13
18:22:27 <felixfontein> #info Galaxy: https://galaxy.ansible.com/hpe/nimble
18:22:29 <felixfontein> #info Repository: https://github.com/hpe-storage/nimble-ansible-modules
18:22:32 <felixfontein> aaaand the next one!
18:22:55 <felixfontein> hmm I guess I should have #action'ed samccann...
18:23:39 <acozine> no worries, we'll take care of the README
18:23:48 <felixfontein> :+1:
18:24:04 <felixfontein> docs team++
18:24:19 <samccann> heh already did it felixfontein
18:24:32 <felixfontein> awesome :)
18:24:41 <cybette> DaWGs rocks
18:25:17 <briantist> 🎵 whoooo let the DaWGs out...
18:25:42 <gundalow> felixfontein: Should `./changelogs/.plugin-cache.yaml` be added to gitignore?
18:26:00 <felixfontein> gundalow: we should probably do that in the collection template (if it isn't already)
18:26:18 <dmsimard> I don't see objections or blockers in the review and the maintainer looks responsive to our feedback, informal +1 from me
18:26:20 <felixfontein> it isn't forbidden to include it, but it's not necessary either... it's basically a cache of the version_added values in the collection
18:26:28 <gundalow> felixfontein: ack, I'll check
18:26:34 <felixfontein> gundalow: thanks!
18:26:40 <felixfontein> dmsimard: I agree
18:27:08 <felixfontein> does anyone have objections, or wants to discuss something?
18:27:21 <gundalow> felixfontein: already there. Though I guess no everybody uses that template repo (which is fine)
18:27:28 <gundalow> no objections from me
18:27:36 <jillr> none from me either
18:27:39 <felixfontein> gundalow: resp. it was added at some point when some collection repos were already created :)
18:27:43 <andersson007_> if no objections, let's vote
18:27:52 <felixfontein> VOTE: should we include hpe.nimble in Ansible 4?
18:27:53 <felixfontein> #chair
18:27:53 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
18:27:55 <jillr> +1
18:27:56 <andersson007_> +1
18:27:59 <felixfontein> +1
18:28:01 <acozine> +1
18:28:02 <tadeboro> Again, maintainers are really responsive.
18:28:04 <tadeboro> +1
18:28:07 <cyberpear> +1
18:28:07 <gundalow> +1
18:28:10 <andersson007_> it's really important
18:28:12 <abadger1999> +1
18:28:15 <dmsimard> +1 (non-committee)
18:28:46 <samccann> +1(what they said)
18:29:20 <felixfontein> #agreed hpe.nimble will be included in Ansible 4
18:29:36 <felixfontein> now comes the netapp series ;)
18:29:37 <felixfontein> #topic Inclusion of netapp.azure in Ansible 4
18:29:37 <felixfontein> #info Discussion: https://github.com/ansible-collections/ansible-inclusion/discussions/17
18:29:40 <felixfontein> #info Galaxy: https://galaxy.ansible.com/netapp/azure
18:29:43 <felixfontein> #info Repository: https://github.com/ansible-collections/netapp
18:29:45 <samccann> cyb-clock-clone sez 29 min into meeting, last topic was 8 min
18:29:59 <felixfontein> tadeboro: thanks for tracking the votes in the issue!
18:31:04 <felixfontein> the netapp collections luckily switched to semver, which makes it possible to include them (and keep the ones we already have included)
18:31:11 <dmsimard> The points that I had highlighted during my review of netapp.azure have been addressed so far as I can tell, though I find it peculiar that the note about code of conduct is nested deep into collection READMEs rather than at the root README -- not a blocker
18:31:23 <dmsimard> also yes, lack of semver would have been a blocker and I am glad they were able to turn that around
18:32:06 <tadeboro> dmsimard: I think having CoC in the nested READMEs is important because that file is rendered on galaxy. But having a link in the repo root would not hurt, I agree.
18:32:23 <felixfontein> indeed
18:32:26 <dmsimard> oh, I suppose you're right
18:32:48 * dmsimard is used to collections being at the root of the repo
18:32:51 <felixfontein> I really don't like this repo structure, but that wasn't a requirement :)
18:32:58 * felixfontein too
18:33:07 <acozine> yeah, the one-repo-many-collections thing is . . . confusing
18:33:31 <samccann> yea has taken me a bit to figure it  out as well.
18:33:40 <gundalow> FYI I've discussed the structure with Partner Engineering Team, we've agreed there shouldn't be any other repos structured like that
18:33:52 <felixfontein> I would understand if community.aws and amazon.aws would using that since they're tightly coupled, but the netapp collections seem to be pretty unrelated
18:33:56 <felixfontein> gundalow: cool!
18:34:15 <jillr> we considered doing it for AWS, but decided against it pretty early on
18:34:18 <samccann> They also still have ANSIBLE_METADATA - doesn't hurt to have it, but might be worth telling them it serves no purpose anymore.
18:34:27 <jillr> we figured releasing would be a whole pain
18:34:33 <dmsimard> felixfontein, gundalow: I think from their perspective, having their collections in a single repo reduces the maintenance overhead and it makes sense to me in that regard
18:34:33 <tadeboro> Well, they created collections at the same time we created Sensu Go (cca. 2 years ago) when collections world was a wild west.
18:34:38 <felixfontein> samccann: it potentially does if you support Ansible 2.9
18:34:39 <abadger1999> Likely one team within netapp working on all of them so to them it's less administrative overhead to set permissions and rules on just one repo.
18:34:53 <dmsimard> abadger1999: yup
18:35:21 <samccann> felixfontein.. huh, didn't know that. Will ask you for clarification later ;-)
18:36:07 <felixfontein> VOTE: should we include netapp.azure in Ansible 4?
18:36:08 <felixfontein> #chair
18:36:08 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
18:36:17 <jillr> +1
18:36:22 <gundalow> +1
18:36:23 <tadeboro> samccann: If metadata is missing, ansible-doc report collection as preview and community-maintained IIRC. This is why we still have that info in sensu.sensu_go.
18:36:25 <felixfontein> +1
18:36:25 <tadeboro> +1
18:36:28 <andersson007_> +1
18:36:31 <acozine> +1
18:36:39 <dmsimard> +1 (non-committee)
18:36:39 <samccann> +1(passenger)
18:36:54 <abadger1999> +1
18:38:05 <felixfontein> cyberpear: ^
18:38:16 <cyberpear> +1
18:38:24 <felixfontein> #agreed netapp.azure will be included in Ansible 4
18:38:25 <tadeboro> cyberpear: If you do not +1, you will break my copy-paste thingy ;)
18:38:41 <felixfontein> or people will wonder why this collection had one less vote ;)
18:38:45 <felixfontein> #topic Inclusion of netapp.cloudmanager in Ansible 4
18:38:46 <felixfontein> #info Discussion: https://github.com/ansible-collections/ansible-inclusion/discussions/16
18:38:48 <felixfontein> #info Galaxy: https://galaxy.ansible.com/netapp/cloudmanager
18:38:51 <felixfontein> #info Repository: https://github.com/ansible-collections/netapp
18:38:53 <felixfontein> next collection, same repo
18:40:07 <samccann> cyb-clock-clone sez we are 40 min into the meeting, last topic lasted 10 min
18:40:59 <felixfontein> (this is the last one in tadeboro's "Ready for inclusion" section)
18:41:30 <jillr> +1 ship it
18:41:55 <felixfontein> VOTE: should we include netapp.cloudmanager in Ansible 4?
18:41:55 <felixfontein> #chair
18:41:55 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
18:42:02 <felixfontein> +1
18:42:05 <tadeboro> +1
18:42:06 <andersson007_> +1
18:42:11 <jillr> +1
18:42:14 <abadger1999> +1
18:42:15 <acozine> +1
18:42:21 <dmsimard> +1 (non-committee)
18:42:44 <samccann> +1(baggage compartment)
18:42:59 <cyberpear> +1
18:43:06 <gundalow> +1
18:43:11 <jillr> lol samccann :)
18:43:11 <felixfontein> #agreed netapp.cloudmanager will be included in Ansible 4
18:43:16 <dmsimard> right there with you samccann :P
18:43:18 <felixfontein> samccann: what will be next? trunk? :)
18:43:34 <samccann> heh
18:43:36 <felixfontein> #topic Inclusion of netapp.um_info in Ansible 4
18:43:37 <felixfontein> #info Discussion: https://github.com/ansible-collections/ansible-inclusion/discussions/18
18:43:39 <felixfontein> #info Galaxy: https://github.com/ansible-collections/ansible-inclusion/discussions/18
18:43:42 <felixfontein> #info Repository: https://galaxy.ansible.com/netapp/um_info
18:44:45 <andersson007_> looks like is ready for inclusion (according to the checklists)
18:44:47 <jillr> oh oops, I didnt check the boxes in my review commment when I re-reviewed, doing that now
18:44:52 <felixfontein> for this one there's a potential issue (we have to decide how serious this is), namely it consists of modules that retrieve information, and they are all called `na_um_list_<object>`, i.e. there's no `_info` in the module name
18:45:16 <acozine> at least they're not called `na_um_facts`
18:45:23 <dmsimard> it looks to me like there is willingness from maintainer to address that and was seeking the right way to do it so I wouldn't classify that as a blocker
18:45:33 <samccann> in general, each of these readmes has a statement about using the `collections` keyword. Again not a blocker, but feels misleading. Yes, if you have an EXISTING playbook, add that keyword and you should be good to go.  But if you are new to it all, you should be using FQCN I think.
18:45:49 <jillr> I'm not inclined to block on the info naming; it would be nice but I don't see it as a hard requirement and they've been responsive
18:45:52 <felixfontein> renaming + deprecating the old name can be done in a minor release, so it is possible to fix this soon (instead of having to wait for the next major release)
18:45:54 <tadeboro> I missed that all of the modules are actually info modules in my review. But apart from the name issue, I found no other problems.
18:46:29 <dmsimard> samccann: quite subjective and can depend on the use case -- typing collection names all the time can be exhausting and I can see why people would rather include it in the collection stanza
18:47:25 <dmsimard> I mean, especially if there are no concerns over clash over namespaces for "common" module names (say, "file")
18:47:40 <samccann> yeah these seem decidedly unique module names
18:47:46 <tadeboro> I think FQCNs are the way to go, but the fact that some of the collections have different names on AH, I can see why `collections: ...` might be useful.
18:48:10 <tadeboro> But in this case, collection name does not change.
18:48:11 <dmsimard> oh yeah, I wish names would be consistent
18:48:16 <samccann> ditto
18:48:19 <felixfontein> yep
18:48:30 <gundalow> If the maintainer has been responsible I could accept a _info rename in a future release. Though would be nice if that happened soon
18:48:31 * abadger1999 on the fence about whether to block on `_info`.  The fact that they're willing to change, just asking if they can delay for a few weeks inclines me towards not blocking this one specifically but do require that people use the _info name.
18:49:01 <acozine> for example tasks, FQCN is best, because that way copy/pasting works with or without the rest of the sample play, but I can absolutely see why people would want to use `collections:`
18:49:07 <abadger1999> We should also add something about _info and _facts naming conventions to the guidelines.
18:49:09 <felixfontein> abadger1999: when is the last time we accept a new minor version of a collection before 4.0.0 is released?
18:49:10 <samccann> have we documented somewhere that information retrieval modules must have `_info` in the name?
18:49:21 <dmsimard> abadger1999: Would that go under general best development practices ? I'm not sure it's necessary to be explicit in the inclusion criteria
18:49:23 <jillr> abadger1999: +1
18:49:40 <jillr> iirc it's in the general ansible devel docs but it would be good to highlight it for collections
18:49:48 <jillr> or at least link to it
18:50:02 <abadger1999> https://docs.ansible.com/ansible/devel/roadmap/COLLECTIONS_4.html    05-11.
18:50:08 <samccann> cyb-clock-clone sez we are 50 minutes into the meeting, and 7 min into the current topic
18:50:14 <acozine> samccann: https://docs.ansible.com/ansible/latest/dev_guide/developing_modules_general.html#creating-an-info-or-a-facts-module talks about info modules
18:50:31 <felixfontein> abadger1999: it also says `Ansible-4.0.0 beta1 – feature freeze` for yesterday :)
18:50:36 <samccann> yeah thinking if it becomes a blocker thing in the future, it needs to be in the checklist
18:50:43 <acozine> and we do say `They MUST be named <something>_info or <something>_facts, where <something> is singular.`
18:50:55 <abadger1999> felixfontein: true :-)
18:51:29 <felixfontein> so if we're in feature freeze from today's beta, it is not possible to have the _info rename happen for Ansible 4.0.0, only for Ansible 4.1.0
18:51:50 <abadger1999> dmsimard: I think the dea is that the inclusion criteria is growing to include development guidelines too (when gundalow breaks them out into their own repo).
18:51:52 <dmsimard> FWIW https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_best_practices.html mentions either _info or _facts
18:52:14 <tadeboro> We do link to https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_best_practices.html#scoping-your-module-s where _info convention is described.
18:52:20 <gundalow> Their collection has already been releases, so NetApp could add a new module in the next release, or maybe before 4.0.0 releases
18:52:48 <felixfontein> gundalow: but we won't include newer minor versions in Ansible 4.0.0 due to feature freeze
18:53:05 <tadeboro> IIRC, their plan is to release the renamed modules in June.
18:53:13 <dmsimard> why so long ?
18:53:15 <gundalow> felixfontein: ah, thanks
18:53:22 <tadeboro> https://github.com/ansible-collections/ansible-inclusion/discussions/18#discussioncomment-650871
18:53:22 <felixfontein> that's long indeed
18:53:27 <cyberpear> not sure if it's the point of concern, but my interpretation is that if it's something that `setup` might reasonably gather, it should be `_facts`... if it's not specific to the inventory_hostname, it should be probably _info
18:54:34 <felixfontein> cyberpear: that comes pretty close to the intention I think
18:54:36 <gundalow> I wonder if June is when the next NetApp software update is. I
18:55:38 <felixfontein> considering there is no way the rename will end up in 4.0.0, I think I would prefer if this collection waits for Ansible 5.0.0
18:56:02 <tadeboro> One of the maintainers mentioned the repo restructuring, my guess would be that they do not have the bandwidth to rename things right now.
18:56:12 <gundalow> If this was a brand new collection, I'd agree with felixfontein. Though I believe there are a lot of people using this collection already
18:56:22 <felixfontein> (and I guess starting the rename last Friday shouldn't result in a release in time for today either, since renaming should be followed by a lot of testing to make sure nothing breaks)
18:56:48 <felixfontein> I have no idea how many people are using it
18:56:57 <felixfontein> https://galaxy.ansible.com/netapp/um_info mentions 502 downloads
18:57:07 * andersson007_ could add the requirement about _info / _facts to the checklist tomorrow
18:57:26 <acozine> if they are already using it, then presumably they have installed it as a standalone collection; they could keep doing that even if we don't add it for Ansible 4
18:57:26 <felixfontein> which can be a lot (if no CI downloads this), or not at all (if some CI downloads this)
18:57:37 <abadger1999> I think I'd be okay with it if they were going to get the renamed modules into ansible-4.1.0
18:57:48 <tadeboro> gundalow: This is a relativelly new collection mainly used by the NetApp customers.
18:58:16 <abadger1999> But we don't have a timeline so I don't know if that's a good expectation or not.
18:58:22 <gundalow> tadeboro: ah, OK
18:59:36 <tadeboro> Personally, I would be OK with renaming modules in next two months. But that is just me.
18:59:38 <gundalow> Don't think it's on AutomationHub yet
18:59:48 <felixfontein> I guess they will have their 21.6.0 version (with the rename) out by the end of May
18:59:54 <jillr> gundalow: it's not
18:59:59 <gundalow> jillr: thanks for confirming
19:00:02 <felixfontein> 21.5.0 has been released 6 days ago, so before May :)
19:00:38 <felixfontein> should we vote?
19:00:42 <samccann> cyb-clock-clone sez we are 1 hour into the meeting, and 16 minutes into the current topic
19:00:47 <felixfontein> or do you want to discuss more about this one?
19:01:06 <felixfontein> already 16 minutes, so let's vote :)
19:01:07 <felixfontein> VOTE: should we include netapp.um_info in Ansible 4?
19:01:07 <felixfontein> #chair
19:01:07 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
19:01:13 <gundalow> +1
19:01:20 <tadeboro> +1
19:01:24 <jillr> +1
19:01:25 <andersson007_> +1
19:01:34 <abadger1999> +0
19:01:35 <tadeboro> (Assuming they rename modules in next two months)
19:01:37 <acozine> 0
19:01:44 <cyberpear> +1
19:01:55 <dmsimard> +1 (non committee, with the agreement that they'll do the rename to _info)
19:01:59 <samccann> 0 (trunk)
19:02:02 <samccann> ;-)
19:02:09 <felixfontein> -0 :)
19:03:09 <tadeboro> Right now we are at 5 x +1, 3 x 0.
19:03:16 <felixfontein> so steering committe: 5 x +1, 3 x 0, community: 1 x +1, 1 x 0
19:04:08 <abadger1999> Yeah.  So it seems to pass.
19:04:50 <tadeboro> I interpret the results the same way.
19:05:01 <felixfontein> if nobody vetos, I think it does
19:05:10 <jillr> agreed
19:05:40 <felixfontein> #agreed netapp.um_info will be included in Ansible 4
19:06:14 <felixfontein> should we add a statement to the meeting notes that we expect the modules to be renamed for Ansible 4.1.0, i.e. by June 8th?
19:06:29 <andersson007_> +1
19:06:35 <felixfontein> (do we need a vote on that?)
19:06:56 <tadeboro> I am adding those notes to the voting issue + I will open a bug report on the  netapp repo.
19:07:04 <felixfontein> :+1:
19:07:04 <tadeboro> I do not thing vote is needed here.
19:07:04 <jillr> I feel like we were all in agreement about that
19:07:34 <felixfontein> #info We expect the modules to be renamed to _info so the new names will be available in Ansible 4.1.0. This means this has to be in a minor release by June 8th
19:07:42 <felixfontein> good :)
19:07:44 <felixfontein> three to go
19:07:45 <felixfontein> #topic Inclusion of equinix.metal in Ansible 4
19:07:45 <felixfontein> #info Discussion: https://github.com/ansible-collections/ansible-inclusion/discussions/15
19:07:48 <felixfontein> #info Galaxy: https://galaxy.ansible.com/equinix/metal
19:07:50 <felixfontein> #info Repository: https://github.com/equinix/ansible-collection-metal
19:08:10 <samccann> cyb-clock-clone sez we are 67 min into meeting
19:08:15 <acozine> `CI does not run against ansible-core-2.11` == hard no from me
19:08:16 <felixfontein> here, the maintainers were basically silent until 12 days ago
19:08:52 <felixfontein> acozine: yep, and it didn't change until today
19:09:00 <jillr> it looks like they just asked fo rmore clarity on the tracking issue  https://github.com/ansible-community/community-topics/issues/10#issuecomment-828700761
19:09:07 <felixfontein> (just checked)
19:10:05 <andersson007_> they didn't put a comment that the collection is ready (as I asked them), so I didn't do a final review
19:10:28 <jillr> I also didn't do another review for the same reason
19:10:30 <tadeboro> andersson007_: They did no work since your comment, so I also skipped review.
19:11:09 <felixfontein> me neither
19:11:28 <andersson007_> tadeboro: yep
19:11:34 <felixfontein> also most things are mentioned in https://github.com/ansible-collections/ansible-inclusion/discussions/15, and tadeboro also mentioned the deadline (this Monday)
19:11:50 <abadger1999> If they're not doing work regularly, it's entirely reasonable to leave them out of ansible-4.  ansible-5 is just six months away.
19:12:00 <acozine> it sounds like they need a little time to get things polished
19:12:16 <andersson007_> i think we should skip the collection, it's not ready
19:12:17 <acozine> Ansible 5 may be just the timeline they need
19:12:18 <felixfontein> VOTE: should we include equinix.metal in Ansible 4?
19:12:18 <felixfontein> #chair
19:12:18 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
19:12:22 <andersson007_> -1
19:12:23 <felixfontein> -1
19:12:23 <acozine> -1
19:12:28 <tadeboro> -1
19:12:31 <dmsimard> 0
19:12:43 <samccann> -1 (sitting on curb with luggage at her back, questioning life choices)
19:12:44 <gundalow> -1 (though I hope to see them in 5.0)
19:12:49 <cyberpear> -0
19:13:07 <felixfontein> if they really start fixing things, and will be more reactive, 5.0.0 should be no problem
19:13:16 <jillr> -1
19:13:26 <abadger1999> -1
19:13:43 <felixfontein> #agreed equinix.metal will not be included in Ansible 4 (but 5 is possible if the issues are resolved by then)
19:13:56 <gundalow> I think it's just slightly bad timing, no indication that they won't make it into 5.0
19:14:02 * gundalow needs to set out for a bit
19:14:21 <felixfontein> two collections are left..
19:14:21 <felixfontein> #topic Inclusion of infoblox.nios_modules in Ansible 4
19:14:21 <felixfontein> #info Discussion: https://github.com/ansible-collections/ansible-inclusion/discussions/11
19:14:25 <felixfontein> #info Galaxy: https://galaxy.ansible.com/infoblox/nios_modules
19:14:27 <felixfontein> #info Repository: https://github.com/infobloxopen/infoblox-ansible
19:15:42 <dmsimard> so I re-reviewed this one before the meeting and even though they have done some improvements, it's not quite there yet IMO
19:15:43 <felixfontein> I'm -1 on this one, they didn't really do anything for a long time (they already applied for inclusion in Ansible 3!)
19:16:30 <dmsimard> they fixed an issue with 2.11 and I pointed them in the right direction regarding how most of their modules have "supports_check_mode=True" without actually doing anything with check mode
19:16:42 <abadger1999> :-(
19:17:00 <felixfontein> they fixed the 2.11 issue like a month after I created an issue about it in their repo...
19:17:04 <jillr> I'm concerned about the collection just plain not working only a few days ago, I feel like this one needs more testing/review
19:17:18 <abadger1999> Yeah, claiming check_mode support but making changes in check_mode seems pretty bad.
19:17:30 <andersson007_> :)
19:17:46 <tadeboro> The main issue I have with this collection is responsiveness. Maintainers seem to do something only if there is a "stick" involved.
19:17:53 <felixfontein> right now most of their modules are also in community.general, and I would really like to remove them there
19:18:09 <felixfontein> tadeboro: and if the stick is made obvious
19:18:17 <jillr> tadeboro: yeah we shouldn't have to chase them down whenever there's a bug report
19:18:21 <acozine> except it seems like the ones in c.g are slightly better maintained
19:18:37 <abadger1999> Heh :-)
19:18:45 <felixfontein> acozine: unfortunately yes... and I say unfortunately because they aren't really maintained ;)
19:18:49 <felixfontein> (in c.g)
19:18:53 <dmsimard> well yes, in fact, there are bugfixes in c.g that aren't in the infoblox collection
19:18:56 <acozine> sadly true
19:19:07 <samccann> they have a series of playbooks within the collection itself. Some use FQCN, some do not  (and those that don't also do not have `collections` keyword near as I can tell)
19:19:10 <abadger1999> felixfontein: I suppose  removing content from community.general is something we should talk about for the next development cycle.
19:20:02 <felixfontein> abadger1999: yep, I'm currently thinking of deprecating these modules in c.g and removing them in a few major versions, no matter whether their collection will be included or not. but that's something for aonther community meeting :)
19:20:24 <tadeboro> I think we should discuss the way forward some other time.
19:20:27 <felixfontein> VOTE: should we include infoblox.nios_modules in Ansible 4?
19:20:27 <felixfontein> #chair
19:20:27 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
19:20:31 <felixfontein> -1
19:20:31 <abadger1999> -1
19:20:31 <andersson007_> -1
19:20:31 <tadeboro> -1
19:20:34 <dmsimard> -1
19:20:37 <dmsimard> (non-committee)
19:20:39 <jillr> -1
19:20:44 <acozine> -1
19:21:19 <felixfontein> samccann: which part of the car is it this time? :)
19:21:26 <cyberpear> -0
19:21:40 <acozine> wheel-well, maybe?
19:21:52 <gundalow> -1
19:21:54 <dmsimard> the roof rack
19:22:01 <samccann> heh
19:22:24 <samccann> -1 (walks back home, towing luggage behind her)
19:22:32 <felixfontein> #agreed infoblox.nios_modules will not be included in Ansible 4
19:22:40 <felixfontein> #topic Inclusion of cisco.dnac in Ansible 4
19:22:41 <felixfontein> #info Discussion: https://github.com/ansible-collections/ansible-inclusion/discussions/20
19:22:44 <felixfontein> #info Galaxy: https://galaxy.ansible.com/cisco/dnac
19:22:46 <felixfontein> #info Repository: https://github.com/cisco-en-programmability/dnacenter-ansible
19:22:49 <felixfontein> and the last one :)
19:22:58 <samccann> cyb-clock-clone sez 1hr. 20 min into the meeting
19:23:35 <jillr> I think the review issue needs a comment summarizing what specifically is being asked for as a result of the conversation about the design. ie; please improve the UX in the following ways.
19:23:39 <acozine> if `Collection fails some import tests on what will become ansible-core-2.11` is still true, this one's another hard no
19:23:44 <felixfontein> this one is missing our beloveth idempotence :)
19:24:05 <acozine> heh
19:24:52 <acozine> that's not a blocker from my perspective, as long as it's well documented
19:25:09 <cyberpear> missing idempotence problematic for me
19:25:23 <cyberpear> unless it's impossible to implement
19:25:23 <jillr> like, the discussion between tadeboro and cidrblock is really good, but I don't think we gave the maintainers a clear action item from it
19:25:41 <felixfontein> tadeboro and cidrblock looked at it in much more detail I think, at least to me it seems like the content in this collection are basic building blocks which are better than nothing, but not close to what users expect from Ansible modules
19:26:02 <dmsimard> I'll abstain for now and read, a bit out of my element on that one
19:26:48 <tadeboro> jillr: The discussion is mostly pointless for cisco.dnac because that issue was actually fixed by the maintainers (they added parameters to modules and released 2.0.0).
19:26:51 <acozine> jillr: agreed that more specific direction would help the maintainers, though I'm not inclined to add them to Ansible 4 for that reason alone
19:26:51 <jillr> I'm generally inclined to defer to cidrblock's expertise on atypical network modules  :)
19:26:59 <felixfontein> acozine: we usually still except some very basic idempotence, so that if you specify state=create, it won't error out when the object already exists and forces you to use state=update in that case
19:26:59 <jillr> tadeboro: ah ok
19:27:21 <acozine> felixfontein: ah, at that level
19:27:44 <tadeboro> The main issue I have with that collection is that all modules are regular module + info module in one.
19:27:48 <felixfontein> I haven't checked whether that's still the case though
19:27:49 <acozine> that's as much "polite UX design" as "idempotence"
19:28:06 <felixfontein> yeah, that's also something we don't want (and have been saying so for a long time)
19:28:18 <jillr> and thanks very much tadeboro for all the work investigating this one
19:28:23 <gundalow> Does Cisco's underlying API support the functionality we want?
19:28:53 <felixfontein> gundalow: it doesn't seem to make full idempotence easy, but it does allow a lot more than what seems to be implemented
19:29:54 <tadeboro> gundalow: From my experience, API is useless if one cannot query state in a meaningfull way. But I do not have access to DNA Center, so I cannot be sure if this is actually the case here.
19:29:59 <felixfontein> the example in https://github.com/ansible-collections/ansible-inclusion/discussions/20#discussioncomment-606904 is very telling IMO
19:30:47 <felixfontein> that's the very basic I would expect a module to do, playbook/role authors should not have to write that themselves
19:32:07 <abadger1999> <nod> If the API allows querying, it may be that the module could do the right thing (query, then perform either a create or update depending on what already exists).  If the module only lightly wraps the API, then it would seem that the module is at fault.
19:32:34 <abadger1999> If we decide this is a blocker, we should make an addition to the guidelines about it as well
19:34:04 <felixfontein> I would even expect that to be part of the best pratices in https://docs.ansible.com/ansible/devel/dev_guide/developing_modules_best_practices.html
19:34:08 <samccann> cyb-clock-clone sez we are 1hr 33 min into the meeting and 12 min into the current topic
19:34:29 <tadeboro> I do not see this as a strict blocker, just something that could be greatly improved. Having a `state: query` combo a blocker for me here because this is actually documented.
19:34:51 <felixfontein> ok, should we vote? we can discuss how to improve the situation (better feedback, better guidelines/rules/...) later / next week / ...
19:35:50 <abadger1999> Does anyone have another point htey'd like to raise before we vote?
19:36:05 <tadeboro> Not me.
19:36:17 <gundalow> What do we think they can realistically do to make the collection better?
19:36:21 <jillr> none from me
19:36:58 <jillr> gundalow: aiui, split the query/info behaviour into separate modules
19:37:00 <felixfontein> gundalow: IMO they need to create new modules (or action plugins, whatever they want) that have a better interface. it's probably better to do this in new modules instead of updating the existing ones, but that's basically up to them
19:37:20 <tadeboro> gundalow: Split the _info part into separate module, work on enforcing state instead of executing actions.
19:37:22 <acozine> passing all tests would also be good
19:37:41 <jillr> ah yeah tests passing is always good  :)  +1
19:37:45 <felixfontein> indeed :)
19:38:01 <felixfontein> VOTE: should we include cisco.dnac in Ansible 4?
19:38:02 <felixfontein> #chair
19:38:02 <zodbot> Current chairs: abadger1999 acozine andersson007_ briantist cyberpear cybette dericcrago dmsimard felixfontein gundalow jillr samccann tadeboro
19:38:06 <felixfontein> (otherwise we'll never finish this :D )
19:38:11 <acozine> -1
19:38:12 <felixfontein> -1
19:38:13 <abadger1999> -1
19:38:14 <jillr> -1
19:38:14 <tadeboro> -1
19:38:26 <andersson007_> -1
19:38:32 <cyberpear> -1
19:38:42 <samccann> -1 (unpacks luggage ...this trip's over)
19:38:49 <jillr> lol
19:39:04 * felixfontein has to think of another vote for today to find out what samccann will then use :D
19:39:10 <gundalow> 0
19:39:32 <felixfontein> #agreed cisco.dnac will not be included in Ansible 4
19:39:46 <samccann> heh
19:40:19 <felixfontein> ok, should we discuss improvements for this collection more? if not, I'd continue with Open Floor
19:40:31 <felixfontein> (so we can finally wrap this up for today... it has been a really long meeting!)
19:40:43 <felixfontein> like the 'good old times' :)
19:40:47 <acozine> heh
19:41:13 <tadeboro> I say we work on suggestions in an async fashion until the next meeting.
19:41:22 <felixfontein> sounds good to me
19:41:30 <dmsimard> +1, productive meeting thanks everyone
19:41:33 <felixfontein> should we create a new issue for that, or re-use your current issue?
19:41:36 <acozine> maybe we could add a "follow up with collections that didn't make it into Ansible 4" item to a meeting in a few weeks' time
19:41:36 <felixfontein> #topic Open Floor
19:41:44 <acozine> \o/
19:41:48 <felixfontein> acozine: sounds good!
19:41:59 <felixfontein> acozine: please create an issue :)
19:42:03 <acozine> will do
19:42:05 <gundalow> Is someone able to add specific actions for cisco.dnac to the discussion?
19:42:29 <acozine> one general question . . . do we invite maintainers specifically to the community meetings?
19:42:31 <cyberpear> is there an issue tracking shipping a wheel vs just setup.py on PyPI?
19:42:44 <tadeboro> I will add a comment to all inclusion requests with a link to the meeting log (just for reference).
19:43:16 <tadeboro> And I think a separate issue would be better for the follow-up things.
19:43:20 <felixfontein> cyberpear: for ansible-core, or for ansible itself? right now the blocker on a wheel are the frequent renames (ansible -> ansible-base -> ansible-core)
19:43:41 <cyberpear> I guess ansible since this is our purview
19:43:52 <cyberpear> I'd guess maybe they need to be coordinated?
19:43:58 <dmsimard> acozine: I would like to say that everyone is invited and welcome
19:44:16 <acozine> they are, for sure
19:44:27 <abadger1999> cyberpear: there isn't.  I think the warning about uninstalling old ansible is the only thing that prevents us doing that.
19:44:39 <acozine> just thinking if the maintainers had been able to come, we could have given them direct feedback today
19:45:03 <felixfontein> acozine: that might have increased the length of the meeting a lot :)
19:45:11 <acozine> felixfontein: heh, true
19:45:11 <tadeboro> acozine: I would rather see maintainers ask us questions a few week ago.
19:45:15 <felixfontein> yes
19:45:19 <acozine> I retract the suggestion
19:45:22 <tadeboro> *weeks
19:46:00 <cyberpear> they're always welcome to join these public meetings, but we don't need to send an invitation unless we have something that needs real-time discussion
19:46:00 <felixfontein> it would be nice if maintainers react quicker, I remember we had a collection review day several weeks ago and had almost nothing to do since most collections did not yet react on the review(s) they already had
19:46:27 <jillr> a comment when a new inclusion request is first opened that they can come to the meeting maybe, so we can engage them early
19:46:52 <felixfontein> jillr: probably makes more sense if there is at least one review (and the reviewer is around) :)
19:46:52 <jillr> and perhaps a reminder as the review goes along
19:47:10 <jillr> felixfontein: true enough
19:47:37 <tadeboro> I did try to ping people when the due date approached, but I did not advertise irc there.
19:48:21 <jillr> it might be good to link to webchat too, in case folks are not familiar with irc
19:49:13 <felixfontein> we should have a doc with that anyway, that would also help random community members to take part in the meeting
19:49:22 <felixfontein> (we might even have somewhere...)
19:49:53 <jillr> we have it on https://github.com/ansible/community/wiki/Diversity but I don't see it on the Community wiki page
19:50:35 <samccann> Meanwhile, I promised to mention someone has a collections question over on #ansible-docs (testing docs within a collection). I said someone here might know the answer and be able to help them out after this meeting.
19:51:09 * gundalow has to drop off now. Thanks all
19:51:52 <felixfontein> #endmeeting