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