19:00:16 #startmeeting Ansible Community Meeting 19:00:16 Meeting started Wed Jan 27 19:00:16 2021 UTC. 19:00:16 This meeting is logged and archived in a public location. 19:00:16 The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:16 Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:00:16 The meeting name has been set to 'ansible_community_meeting' 19:00:16 #topic Agenda https://github.com/ansible/community/issues/539 19:00:21 abadger1999 acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro: ping! 19:00:27 #topic Updates 19:00:27 #info Ansible 2.10.6 has been released 19:00:27 #info community.network 2.0.0 has been released today, community.general 2.0.0 will be released tomorrow 19:00:34 Good day! 19:00:39 'ello 19:00:40 #chair abadger1999 19:00:40 Current chairs: abadger1999 felixfontein 19:00:40 Hello! 19:00:44 #chair briantist lmodemal 19:00:44 Current chairs: abadger1999 briantist felixfontein lmodemal 19:00:51 hello! 19:00:56 #chair acozine 19:00:56 Current chairs: abadger1999 acozine briantist felixfontein lmodemal 19:01:03 o/ 19:01:07 #chair samccann 19:01:07 Current chairs: abadger1999 acozine briantist felixfontein lmodemal samccann 19:01:24 * gundalow waves 19:01:28 #chair gundalow 19:01:28 Current chairs: abadger1999 acozine briantist felixfontein gundalow lmodemal samccann 19:01:29 o/ 19:01:32 #chair tadeboro 19:01:32 Current chairs: abadger1999 acozine briantist felixfontein gundalow lmodemal samccann tadeboro 19:01:39 ping fest ;) 19:02:12 * acozine enjoys the little brrr-rrr sound, as long as she's already looking at the chat 19:02:28 * dericcrago waves 19:02:34 #chair dericcrago 19:02:34 Current chairs: abadger1999 acozine briantist dericcrago felixfontein gundalow lmodemal samccann tadeboro 19:02:45 o/ 19:02:49 acozine: I just see colors ;) 19:02:51 #chair dmsimard 19:02:51 Current chairs: abadger1999 acozine briantist dericcrago dmsimard felixfontein gundalow lmodemal samccann tadeboro 19:03:48 o/ 19:04:06 cybette: gundalow: do you want to announce the vote for the contributor summit, or is it now over anyway? 19:04:09 #chair cybette 19:04:09 Current chairs: abadger1999 acozine briantist cybette dericcrago dmsimard felixfontein gundalow lmodemal samccann tadeboro 19:05:47 about today's topics: we have some proposals for new/updated rules (https://github.com/ansible/community/issues/539#issuecomment-763981413, https://github.com/ansible-collections/overview/pull/150, https://github.com/ansible/community/issues/539#issuecomment-766905372, https://github.com/ansible-collections/overview/pull/151) 19:05:48 https://github.com/ansible-collections/overview/pull/150, | open, created 2021-01-22T07:07:09Z by abadger: Limiting plugin types 2 19:05:49 https://github.com/ansible-collections/overview/pull/151) | open, created 2021-01-25T12:48:11Z by Ompragash: New Policy Regarding Python Compatibility for Collections 19:06:03 cybette: you want to #info that 19:06:03 I guess https://github.com/ansible-collections/overview/pull/150 is the most urgent 19:06:04 https://github.com/ansible-collections/overview/pull/150 | open, created 2021-01-22T07:07:09Z by abadger: Limiting plugin types 2 19:06:36 then we also have today's deadline for new collections in Ansible 3.0.0 19:06:43 abadger1999: any preference on the order of discussing things? 19:06:59 #info Ansible Contributor Summit 2021.03 will be on March 9 (Tuesday) 19:07:19 I think w must get a decision on whether any new collections are blocking release. 19:07:23 So maybe that first. 19:07:45 #info add topics for Ansible Contributor Summit here: https://hackmd.io/uZDSLOOdS1Kx0xfZVIATmQ 19:07:50 Then rule changes in order of whether we think it's necessary to get any of those collections approved 19:08:12 sounds good to me 19:08:20 do you want to go through them? 19:09:07 I can lead but I haven't been part of the reviews themselves. 19:09:39 We currently have four new collections which are in review. 19:09:53 #topic Inclusion of collections in Ansible 3.0.0 19:10:15 First one (by date submitted): https://github.com/ansible-collections/ansible-inclusion/discussions/3 dellemc.openmanage 19:11:06 So my two questions are: How likely is this to make it through review today? Is this a blocker for the ansible-3.0 release? 19:12:29 dmsimard, felixfontein, andersson007_ ^ 19:12:30 I think that most things are addressed and they want to make a new 3.0.0 release tomorrow. so if we want it included, I think we can finish that process by tomorrow. 19:12:50 dellemc.openmanage maintainer is responsive and has in large part addressed the points brought up in the review -- I don't personally see a blocker for this one 19:13:55 from an FQCN perspective... that is one long collection name! 19:14:25 oh sorry, ignore me - I was looking at the repo name, not the collection name.. doh! 19:14:33 hmm I wonder if the namespace name `c` is still open :) 19:14:49 samccann: Let me introduce you to digitalocean.digitalocean and servicenow.servicenow ;) 19:15:04 haha yeah I've seen the likes of that before tadeboro !! 19:15:25 Okay..... As release manager for the ansible package, I'd be willing to give these collections until 02-02 (beta1 day) if necessary.... What do you folks (the people who have actively been reviewing) think? Do you want to extend the deadline that far? Not quite that far? 19:15:46 for dellemc.openmanage, I think extending the deadline to end of this week is enough 19:16:03 #info We 19:16:04 by then they should have the new version released, and in case we want to include it, we can complete the process 19:16:06 #undo 19:16:06 Removing item from minutes: INFO by abadger1999 at 19:16:03 : We 19:16:14 I'm open to that, though maybe only if we limit to a defined list of collections (those we have in flight) 19:16:20 +1 to felixfontein, I believe their v3.0.0 will be sufficient and land in time for inclusion 19:17:04 VOTE: dellemc.openmanage has until Friday to be approved. If it doesn't make it, it is not a blocker for ansible-3.0 (it will have to wait for ansible-4.0 19:17:19 +1 19:17:21 +1 19:17:22 +1 19:17:26 +1 19:17:38 is dellemc a 'partner' and are there ramifications to that if it doesn't make it into 3.0 community? 19:17:45 +1 19:17:47 +1 19:17:48 * acozine has an uniformed opinion, abstains 19:18:00 samccann: dellemc has certified collections though this is not one of them (at least last I checked on AH( 19:18:09 #info dellemc.openmanage has until Friday to be approved. If it doesn't make it, it is not a blocker for ansible-3.0 (it will have to wait for ansible-4.0) 19:18:15 ah thanks dmsimard 19:18:19 * lmodemal abstains 19:18:40 the criteria for inclusion and certification are different, it is possible for a collection to be in one and not meet the criteria for the other 19:18:46 gundalow: ^ If you know of any ramifications for partners, let us know... otherwise maybe we wshould give a summary to the partner team after we've voted on these four? 19:18:58 with that in mind, being in one does not qualify for a free pass to the other 19:19:12 fun fact: installing all collections included in ansible-2.10.6 with `ansible-galaxy collection install` takes 13 minutes 19:19:20 +1 19:19:24 Second collection: ansible.utils https://github.com/ansible-collections/ansible-inclusion/discussions/4 19:19:28 (and for some reason, it also installs kubernetes.core, which isn't part of ansible-2.10.6) 19:19:50 felixfontein: Can you please raise a bug for that in antsibull 19:20:07 felixfontein: Hmmm.. I hope we don't have a missing dep. We might need to remove a collection 19:20:08 In my experience, rules for certification are almost orthogonal to the rules for ansible inclusion. One focuses on support and the other one more on quality. 19:20:13 gundalow: as soon as I find out which collection that is, I'll do 19:20:13 10 minutes on topic "Inclusion of collections in 3.0.0", 20 minutes into meeting 19:20:39 gundalow: we probably need to check that before build time (or maybe check it in the nightly builds) 19:20:40 ansible.utils is currently missing sanity tests for ansible-base 2.10 19:20:59 #topic staTus of ansible.utils for ansible 3.0.0 19:21:15 (and a new release with the review adjustments and changed subplugin directories) 19:21:34 ganeshrn, pabelanger, felixfontein, tadeboro ^ 19:21:44 19:22:10 don't take this as pure accuracy, but I know they were working toward a new release for those review items. Dunno about the ansible-base 2.10 tests 19:22:14 So same two questions: How likely is this to make it through review today (or by 02-02) ? Is this a blocker for the ansible-3.0 release? 19:22:46 abadger1999: again, going on a partial memory, but didnt' ansible.utils take things out of ansible.netcommon? if so, wouldn't that mean it's a blocker? 19:22:53 IIRC, networking team is working on adding 2.10 sanity tests to Zuul. I do not remember what timeline they set. 19:23:16 Since ansible-3.0 is based on ansible-base-2.10, it seems pretty bad that those tests aren't running. 19:23:31 samccann: It is a blocker only if ansible includes 2.0.0 version. 19:23:35 samccann: I guess we'd have to pin ansible.netcommon to an old version :-( 19:24:09 (Not saying it's not a blocker.... just that there is an alternative) 19:24:14 pabelanger: ikhan We are talkign about `ansible.utils` 19:24:23 are the sanity tests the last item to address ? can we get a commitment to fix it by friday ? 19:24:39 Qalthos: maxamillion FYI ^ 19:25:04 I believe pabelanger said he'd be working on sanity test for network collections next week 19:25:25 Alright... that's probably too late. 19:25:38 well, that the sanity tests MUST be there has been clear for week now. 19:25:41 *weeks 19:25:49 yes, we are adding them now 19:25:53 So... current estimate.... it would not make the 3.0 deadline. 19:26:09 Ah... pabelanger , you're a better source of info... 19:26:33 Is that going to be added by today? Or if not todqay, can it be added before 2-2? 19:27:11 we should have it by 2-2, just waiting on code review, jobs to be finished 19:27:45 https://github.com/ansible-collections/ansible.utils/pull/38 pulls in sanity from devel, and 2.9 inside the EE, 2.10 jobs are testing now 19:27:45 https://github.com/ansible-collections/ansible.utils/pull/38 | open, created 2021-01-26T19:50:41Z by pabelanger: Enable execution environment support 19:27:47 I guess for now adding GitHub Actions to run sanity tests would suffice, that could be removed again once zuul is updated 19:27:56 that would allow to get things moving without blocking everything 19:28:15 I mean, we can just run it locally and share results too 19:29:12 felixfontein: is that satisfactory? and how much time do you need to make sure you've reviewed the collection one last time given its current state? 19:29:30 Since the code quality is really good, I would vote to wait for Zuul to be ready and then include in Ansible 3.0.0 if ready by 2-2 19:30:14 Okay. For you to do review, do you need it be ready for the next review no loater than 2-2 or no later than $EARLIER_DATE? 19:30:15 I'm happy once sanity tests are properly run, against all necessary Python versions (for the tests where that makes sense) 19:30:30 10 minutes on topic "Status of ansible-utils for ansible 3.0.0", 30 minutes into meeting 19:30:47 from what pabelanger wrote it sounds like sanity tests could be there by tomorrow, is that correct? 19:31:10 or how long does running the jobs and reviewing needs? 19:31:46 we can run sanity now, on the collection and share the results. If that is the hold up 19:31:52 pabelanger, felixfontein Shall we say submit by Friday just like dellemc.openmanage? 19:31:54 jobs will be added by 2-2 19:32:40 does it really need to take until 2-2 to add sanity tests to CI? 19:33:07 I mean I can also run them locally, that's not really the point 19:33:34 right, they are passing now, they just are not public tests yet 19:34:21 It feels like we're talking past each other here... 19:34:36 I'm raising a PR to run sanity on 2.10 via GHA 19:35:44 if the remaining PR can be merged soon and potential sanity errors fixed as well, would it be possible to make the new release latest by Friday? 19:36:33 felix needs to know whether he'll have time to review the collection before the deadline. pabelanger needs to know what the deadline is. I need to know if it's worthwhile to extend the deadline (from today to $later_date) so that this can potentially make it into 3.0 19:36:54 right, if 2-2 is the deadline, we cna get it done by then 19:36:59 or it is friday, then we can try 19:37:03 pabelanger: The deadline is today. 19:37:27 yah, I don't think we are releasing today 19:37:31 So we're seeing if we can negotiate an extension. 19:37:34 we are aiming for friday I think 19:37:53 Okay... So felixfontein pabelanger Here's my strawman... 19:38:02 the issue of adding sanity to the jobs, I think is a different topic. Given, CI can be run manually to validate sanity passes 19:38:02 PR with GHA is running: https://github.com/ansible-collections/ansible.utils/pull/39/checks 19:38:42 gundalow: for the unwashed masses (aka me) - does that solve the sanity check conundrum (assuming it passes)? 19:38:54 samccann: I think so 19:38:59 cool 19:38:59 felixfontein: ? 19:39:05 gundalow: it does! thanks for the PR :) 19:39:05 PROPOSAL: ansible.utils has until Friday to be ready for another review. Reviewers can approve or say not ready by 2-2. If it's not approved by 2-2, it has to go to ansible-4 instead. 19:39:16 +1 19:39:17 abadger1999: +1 19:39:35 +1 19:39:44 +1 19:39:46 and ansible.netcommon has to be frozen at an earlier release? That also I think lives that and who knows what else in limbo til 4 I think 19:40:00 pabelanger: Is that okay with you? I know ansible.utils underpines changes that you all want to do.... 19:40:16 I don't know the details, all I know is ansible.netcommon is a dependency for a LOT of other collections. So it may be a bunch of them that cannot go to their next feature release version. 19:40:21 wfm 19:40:32 samccann: yeah :-( 19:40:37 which means that team I think would have to continue bugfixes on older releases for another month maybe? 19:40:58 k. just my point being - has a ripple affect into a good 1/2 dozen other collections potentially, maybe more 19:41:09 20 minutes on topic "Status of ansible-utils for ansible 3.0.0", 40 minutes into meeting 19:41:13 yep, that's why it would be good to have this solved ASAP 19:41:40 ansible.utils Sanity passes on 2.10 via GHA 19:41:45 #info ansible.utils has until Friday to be ready for another review. Reviewers can approve or say not ready by 2-2. If it's not approved by 2-2, it has to go to ansible-4 instead (and there we'll have to figure out what dependent collections cannot be updated either) 19:41:51 gundalow: I think it's enough to add stable-2.10 sanity tests for now, the others will fail for now anyway 19:42:06 ansible.utils Sanity fails on 2.11 (devel) as the collection doesn't support that version 19:42:17 #topic inspur.sm status: https://github.com/ansible-collections/ansible-inclusion/discussions/8 19:42:19 gundalow: exactly 19:42:20 ansible.utils utils tests are failing on 2.10, not sure why 19:42:28 gundalow: missing Python dependency 19:42:29 so, this is what I am confused about. Is the issue that ansible-test sanity for 2.10 results are not published any place? 19:42:38 #undo 19:42:38 Removing item from minutes: 19:42:39 that is blocking the process 19:43:23 pabelanger: the blocker is that ansible-base 2.10 sanity tests are not run in CI 19:43:43 If we could try to wrap this up in under five minutes and have further conversation after the meeting, that would be great. 19:43:51 after is fine 19:43:53 and that some sanity tests for stable-2.9 are not run because you only run the python-3.6 ones 19:43:56 Cool. 19:44:01 #topic inspur.sm status: https://github.com/ansible-collections/ansible-inclusion/discussions/8 19:44:49 felixfontein, tadeboro, dmsimard: How's this one look? 19:44:51 I did review inspur.sm and the maintainer is very responsive and did a great job of getting things ready. At the moment, the only thing missing is a release with all of the changes. 19:45:18 Legal issues seem solved. 19:45:18 Have they added deprecation notices for the non-CRUD modules? 19:45:19 the maintainer for inspur.sm is responsive, and I think most issues have been resolved, as for dellemc.openmanage the main remaining question is whether we want this included or not. 19:45:55 I've been very impressed with inspur for fixing everything 19:46:12 yes, definitely 19:46:16 So I would propose we give maintainer a day or two for a new release and then include it in Ansible 3.0.0 19:46:20 especially as it seems to be only one person working on this 19:46:28 The issue is what? That it's a thin wrapper around the API? Which, for end users, means.... not idempotent? 19:47:16 abadger1999: That collection contained modules such as add_user, del_user, edit_user. 19:47:27 I have no idea whether it is idempotent or not. I didn't really check the library it depends on yet, and it also depends on the API itself - maybe it is kind of idempotent 19:47:51 Heh :-) 19:47:57 The maintainer addressed most of the concerns that were brought up during the review, though it may benefit from some additional time to work out deprecations and removals 19:48:07 19:48:11 abadger1999: But they replaced it with the more commom layout of a single user module that knows how to do all of those operations. 19:48:40 Okay, so it sounds like they're responsive and doing well.. need one more collection release. 19:48:49 I am 50/50 on this one, to be honest the quality is not as high as some of the other applications we've had but this isn't a blocker by itself 19:49:23 VOTE: inspur.sm has until Friday to be ready for another review. Reviewers can approve or say not ready by 2-2. If it's not approved by 2-2, it has to go to ansible-4 instead. 19:49:29 +1 19:49:31 +1 19:49:34 +1 19:49:35 +1 19:49:36 +1 19:49:46 +1 19:49:51 +1 19:49:58 #info inspur.sm has until Friday to be ready for another review. Reviewers can approve or say not ready by 2-2. If it's not approved by 2-2, it has to go to ansible-4 instead. 19:50:14 +1 let's reward responsiveness 19:50:51 #topic infoblox.nios_modules status https://github.com/ansible-collections/ansible-inclusion/discussions/11 19:51:03 (late +1) 19:51:13 50 minutes in the meeting! moving along great! 19:51:15 infoblox.nios_modules came very late to the party 19:51:51 the application officially was made 2 days ago (https://github.com/ansible-collections/ansible-inclusion/discussions/11#discussioncomment-308541) 19:51:52 Infoblox had a late application and has only had one review and could benefit from another, they are responsive but there is also work to do -- I'm not optimistic about it being ready in time for 3.0 but could be a candidate for 4.0 19:52:04 Yeah... the others were all in December. this one was 8 days ago. 19:52:10 also, I'm not sure how familiar they are with Ansible 19:52:41 I did look at this collection some months ago, and it was in not a very good shape, and it needed a lot of outside help to remove a lot of problems 19:53:20 19:53:52 background: the modules it contains are all (or almost all?) contained in community.general, and the hope was to be able to remove them there 19:53:56 I'm okay with saying that we won't get to another review of it by the deadline, today, due to the late submission. 19:54:39 We could also say, have until Friday since that's what we seemed to do for all the others. But I don't want to do that if we're already loading up as much review work as we can take. 19:54:49 I mean we can also extend the deadline for them until Friday, but that's it for 3.0.0 IMO - no need to block the 3.0.0 release 19:55:04 right -- I don't see this as a blocker to Ansible 3.0 19:55:15 if there aren't enough positive reviews until Friday, I guess they have to wait 19:55:46 We can delay until Friday, but I do not see them making it. 19:55:55 for me the bar is how many of the fixes that were made in community.general they manage to incorporate until friday 19:55:57 yeah we have stated since early December (in multiple Bullhorn issues) that collections should be submitted as early as possible 19:56:03 tadeboro: I agree 19:56:03 People who doing reviews, would you like to tell them we'll continue to review but this is going to have to target ansible-4.0 toaday or see if they can make all necessary changes before Friday? 19:56:18 abadger1999: I can take it 19:56:18 But then again, IIRC, this is a certified collection (if this makes any difference). 19:56:28 I'm the only one who has reviewed it so far 19:56:35 Okay cool. 19:56:45 abadger1999: from what I've seen, I doubt they can make it until Friday, but I'm willing to give them a chance 19:56:58 I don't think 'certified' makes any difference 19:57:08 I did review it, but did not start the official review because there just too many things out of place. I would for 4.0.0 directly. 19:57:08 from what I've seen certified collections doing so far 19:57:13 representing again.. the unwashed masses - does this mean we would have basically the same modules in community and in this new collection? 19:57:31 (in Ansible 3) 19:57:45 VOTE: dmsimard will take responsibility for reviewing infoblox.nios_modules. We'll give them until Friday to be approved for 3.0 but will not block the ansible-3.0 release. It will target ansible-4 if it isn't ready by then. 19:57:49 * samccann thinks it's well past time the masses takes a shower really 19:57:51 samccann: yes. and they definitely won't be removed for community.general 2.0.0 anymore, so there will be no redirects until at least Ansible-4.0.0 19:58:06 +1 19:58:08 +1 19:58:09 +1 19:58:14 +1 19:58:23 ok ? I guess :D 19:58:37 FYI Infoblox have known and been talking about taking there modules out of community.general into a dedicated collections since before July 2020 19:58:38 0. I worry about duplicated modules in Ansible 3.x 19:58:51 I thought dmsimard already reviewed this collection? 19:58:58 but nobody else has? 19:59:01 gundalow: they have. unfortunately they never really made an effort from my POV 19:59:03 did I misinterpret? 19:59:04 my preference would be to see them removed from c.g at the same time (aka ansible 4) 19:59:12 I guess it's more like.... guiding the review to approval? 19:59:22 felixfontein: That's my impression as well 19:59:49 I just didn't want us to say "You have until Friday" but then there's no one on our side who is free to review the work that they get done by Friday. 19:59:58 gundalow: otherwise we could have just grandfathered their collection in as community.postgresql, community.docker, cisco.nso etc. 20:00:21 if they have everything done by Friday, I'll happily review it 20:00:26 #info dmsimard will take responsibility for reviewing infoblox.nios_modules. We'll give them until Friday to be approved for 3.0 but will not block the ansible-3.0 release. It will target ansible-4 if it isn't ready by then. 20:00:32 #undo 20:00:32 Removing item from minutes: INFO by abadger1999 at 20:00:26 : dmsimard will take responsibility for reviewing infoblox.nios_modules. We'll give them until Friday to be approved for 3.0 but will not block the ansible-3.0 release. It will target ansible-4 if it isn't ready by then. 20:00:43 10 minutes on topic "infoblox.nios_modules status", 1 hour into meeting 20:00:46 #info dmsimard will take responsibility for guiding the review of infoblox.nios_modules. We'll give them until Friday to be approved for 3.0 but will not block the ansible-3.0 release. It will target ansible-4 if it isn't ready by then. 20:01:46 #info New hard deadline for all the collections (of Friday) to be ready for final review and none of them block the release of ansible-3. 20:02:01 and I guess new applications won't be accepted anymore? 20:02:06 (at least not for 3.0.0 :) ) 20:02:07 felixfontein: Okay, do you want to take the next section, new guidelines? 20:02:10 new applications would target 4.0 20:02:14 abadger1999: sounds good 20:02:29 #topic Limiting plugin types (https://github.com/ansible-collections/overview/pull/150) 20:02:30 https://github.com/ansible-collections/overview/pull/150) | open, created 2021-01-22T07:07:09Z by abadger: Limiting plugin types 2 20:02:43 Who will inform the maintainers about today's decisions? 20:02:52 this is an updated proposal by abadger1999 about limiting plugin types 20:02:59 tadeboro: I'll take that (by posting a comment to each discussion) 20:03:06 so far we had an explicit list of plugin types for an explicit list of collections that were allowed to use them 20:03:31 abadger1999: Thank you! 20:03:51 this will be a more general rule, that restricts the number of allowed subdirectories of plugins/ to two (plugins/plugin_utils and plugins/sub_plugins) 20:03:55 abadger1999: thanks! 20:04:18 (of course, next to the subdirectories supported by ansible-base/-core) 20:04:56 ansible.netcommon and ansible.utils are changing to satisfy this rule, and all other exceptions we had only used plugin_utils anyway 20:05:13 comments/questions on this proposal? 20:05:17 ganeshrn / pabelanger and sivel / nitzmahone: This is the proposal as a result of the discussions we had last week. 20:06:05 I think it satisfies everything that you all brought up about the subdirs of the plugins directory; 20:06:20 I personally like the proposal, it should make everyone happy and minimize the number of new subdirectories 20:06:31 * nitzmahone looks 20:06:47 I like the small number of added directories. So +1 from me. 20:07:37 I'm good with that- lemme poke Matt C for the ansible-test/sanity side of things 20:07:47 I like it but I'll wait to make sure nitzmahone looks before registering my +1 20:08:04 abadger1999: the PR removes language about a temporary exception for `cli_parsers`, `fact_diff`, and `validate` directories - what will we do with those existing directories? 20:08:32 acozine: ganeshrn said his team is moving those directories under plugins/sub_plugins/ 20:08:43 ah, thanks! 20:08:56 Thanks for checking :-) 20:09:48 looks like a clean, clear, easily understood policy to me, +1 20:10:35 Matt C is looking at it right now WRT ansible-test et al 20:10:41 Cool. 20:11:24 But yeah, +1 from me- it meets my wishes of keeping the list contained at least for "official" collections that we're shipping 20:12:20 10 minutes on topic "Limiting plugin types", 1H12M into meeting 20:12:20 Why are these plugin types explicitly listed? ``doc_fragments``, ``modules``, ``module_utils``, ``terminal`` 20:12:36 mattclay: because they aren't listed on the docs.a.c page 20:12:39 They're already listed in the referenced source file: https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/loader.py 20:12:58 mattclay: I've opened a ticket to update the docs.a.c page and once that's done, they can be removed from here. 20:13:11 +1, was gonna say I think that's an oversight on our part ;) 20:13:21 the source file is hard to read for most people who aren't familiar with the general structure of that file, so having a more accessible list is better 20:13:28 yeah 20:13:43 Yeah, the docs should be updated to match the source so we don't need to have a separate list. 20:13:52 what is `plugin_utils` for exactly? 20:14:05 * lmodemal Have to leave this meeting early. Good meeting :) 20:14:11 briantist: it's similar to module_utils, but cannot be used by modules, so it can contain code that's invalid for modules 20:14:15 bye lmodemal! 20:14:47 briantist (eg, as the controller version and target versions drift further apart, you can have Python 3.10 code that will fail Python 2.7 sanity) 20:14:57 `module_utils` can/is can be used for plugins too right? Is this more of a logical distinction then? 20:15:01 briantist: For code, shared by inventory plugins, filters, ... 20:15:02 Ah ok for testing too 20:15:13 briantist: it can, but if you import things from ansible that modules cannot import, the sanity checks will scream at you ;) 20:15:15 Are `sub_plugins` always going to be controller-only? 20:15:38 until someone wants to use em in module 20:15:49 All current known usages are, but may not always be Python 20:15:49 mattclay: assuming nobody writes a crazy action plugin that pushes them to the remote, yes 20:16:06 They can be loaded as resources 20:16:54 If `sub_plugins` are intended to be controller-only, then the docs should mention that as well. 20:17:31 I could clarify that wording.... How about `:sub_plugins: For other plugins which are managed by modules inside of collections instead of by ansible-core. We use a subfolder so there aren't conflicts when ansible-core adds new plugin types.` 20:17:36 Ideally, we use the list for now to stop the bleeding, then at some point provide a way for a collection to opt-in arbitrary subdirs for things like sanity 20:18:03 mattclay: ^ 20:18:07 (eg an ansible_test_config section in metadata or something) 20:18:11 most sanity tests that apply to all existing plugin types are already run for arbitrary directories 20:18:32 Yeah, that works for now as well, but could be problematic in the future 20:19:19 So ansible-doc won't work on sub_plugins, right? 20:19:26 Correct. 20:19:29 yes 20:19:47 Not to say that couldn't be addressed in the future either, but it's not a big issue ATM 20:20:18 It would be easy to add a sanity test to check for these rules. 20:20:32 (goes back to that whole sidecar docs/metadata thing) 20:21:37 I'm not sure `sub_plugins` is the best name, but I haven't thought of anything better. 20:21:50 mattclay: +1 20:21:58 and we kind of have to make a decision now. 20:22:11 20 minutes on topic "Limiting plugin types", 1H22M into meeting 20:22:15 So... perfect is the enemy of the good. 20:22:16 Hrm- `user_plugins`, `custom_plugins`? 20:22:21 Did the name already go through bikeshedding? 20:22:27 yes-ish 20:22:42 and ganeshrn doesn't appear to be around so I'd rather not change it out from under him. 20:22:44 I don't love it either, but I don't have a really strong opinion :) 20:22:44 nitzmahone: I like both of those better than `sub_plugins` 20:23:02 (even though I like custom_plugins better too) 20:23:05 naming things is hard :) 20:23:11 plugins_shared .. they are not really plugins but shared code for em 20:23:20 Well, subplugins are 20:23:20 abadger1999: What's the reason for needing to decide now? 20:23:42 ^ publishing the networking collections that use this 20:23:44 mattclay: ansible.utils and ansible.netcommon need to be released the next days with these changes 20:23:47 Maybe just say we're good with everything, final naming TBD 20:24:06 nitzmahone: the issue is that naming affects import statements aka code 20:24:10 so the name should better be known today, otherwise the schedule blows up :) 20:24:16 mattclay: deadline for accepting new collections (which need this) and networking is publishing collections that use it. So they would have to move their directories again and deprecate a second location. 20:24:38 which is kind of unfair to them 20:25:51 As cybette pointed out, we're over 20 minutes on this... I think we should vote rather as long as the only objections are of the minor bikeshed sort. 20:26:02 (other issues or major bikeshed are okay) 20:26:28 Yeah, I think if it takes an extra day to get a name that's better for something that's going to live a long time, take the day, but again, I don't have a really strong opinion :D 20:26:41 plugins/_shared 20:26:46 abadger1999: I added a suggestion to change 'modules' to 'action plugins', since modules cannot access that folder 20:27:11 felixfontein: what do we do with action plugins then? 20:27:26 bcoca: huh? 20:27:35 bcoca: I'm talking about https://github.com/ansible-collections/overview/pull/150#discussion_r565610306 20:27:36 we already have 'action' plugins 20:27:43 felixfontein: Merged 20:28:02 New wording of that line is `:sub_plugins: For other plugins which are managed by action plugins inside of collections instead of ansible-core. We use a subfolder so there aren't conflicts when ansible-core adds new plugin types.` 20:28:03 bcoca: this is about the text of the proposal, 20:28:27 maybe we should just say plugins instead of action plugins, since lookups can also use them 20:28:35 (the fact that most things under `sub_plugins` are loaded by actions, not modules) 20:28:43 and tests/inventory/etc .. 20:28:44 (I think I remember that ansible.utils has lookups which load these as well) 20:28:45 felixfontein: Or perhaps `non-module` plugins would be more accurate. 20:28:59 mattclay: yes, that would be the unified approach :) 20:29:08 its really local vs remote 20:29:38 `:sub_plugins: For other plugins which are managed by action plugins inside of collections instead of ansible-core. We use a subfolder so there aren't conflicts when ansible-core adds new plugin types.` 20:29:38 module_utils/modules are usable for remote code (as well as local, but not main prupose) 20:30:26 its that what i find confusing, 'managed' or 'used' thought you were introducing new 'action plugin' type 20:30:27 VOTE: Approve https://github.com/ansible-collections/overview/pull/150 (Update the directories allowed in plugins/ ) 20:30:48 +1 20:30:58 +1 both for the current version and mattclay's suggestion 20:30:59 +1 (with reservation on minor naming bikeshed) 20:31:04 +1 20:31:07 +1 20:31:22 +1 20:31:31