ansible_community_meeting
LOGS
19:00:16 <felixfontein> #startmeeting Ansible Community Meeting
19:00:16 <zodbot> Meeting started Wed Jan 27 19:00:16 2021 UTC.
19:00:16 <zodbot> This meeting is logged and archived in a public location.
19:00:16 <zodbot> The chair is felixfontein. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:16 <zodbot> The meeting name has been set to 'ansible_community_meeting'
19:00:16 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/539
19:00:21 <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!
19:00:27 <felixfontein> #topic Updates
19:00:27 <felixfontein> #info Ansible 2.10.6 has been released
19:00:27 <felixfontein> #info community.network 2.0.0 has been released today, community.general 2.0.0 will be released tomorrow
19:00:34 <abadger1999> Good day!
19:00:39 <briantist> 'ello
19:00:40 <felixfontein> #chair abadger1999
19:00:40 <zodbot> Current chairs: abadger1999 felixfontein
19:00:40 <lmodemal> Hello!
19:00:44 <felixfontein> #chair briantist lmodemal
19:00:44 <zodbot> Current chairs: abadger1999 briantist felixfontein lmodemal
19:00:51 <acozine> hello!
19:00:56 <felixfontein> #chair acozine
19:00:56 <zodbot> Current chairs: abadger1999 acozine briantist felixfontein lmodemal
19:01:03 <samccann> o/
19:01:07 <felixfontein> #chair samccann
19:01:07 <zodbot> Current chairs: abadger1999 acozine briantist felixfontein lmodemal samccann
19:01:24 * gundalow waves
19:01:28 <felixfontein> #chair gundalow
19:01:28 <zodbot> Current chairs: abadger1999 acozine briantist felixfontein gundalow lmodemal samccann
19:01:29 <tadeboro> o/
19:01:32 <felixfontein> #chair tadeboro
19:01:32 <zodbot> Current chairs: abadger1999 acozine briantist felixfontein gundalow lmodemal samccann tadeboro
19:01:39 <felixfontein> 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 <felixfontein> #chair dericcrago
19:02:34 <zodbot> Current chairs: abadger1999 acozine briantist dericcrago felixfontein gundalow lmodemal samccann tadeboro
19:02:45 <dmsimard> o/
19:02:49 <felixfontein> acozine: I just see colors ;)
19:02:51 <felixfontein> #chair dmsimard
19:02:51 <zodbot> Current chairs: abadger1999 acozine briantist dericcrago dmsimard felixfontein gundalow lmodemal samccann tadeboro
19:03:48 <cybette> o/
19:04:06 <felixfontein> cybette: gundalow: do you want to announce the vote for the contributor summit, or is it now over anyway?
19:04:09 <felixfontein> #chair cybette
19:04:09 <zodbot> Current chairs: abadger1999 acozine briantist cybette dericcrago dmsimard felixfontein gundalow lmodemal samccann tadeboro
19:05:47 <felixfontein> 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 <github-linkbot> https://github.com/ansible-collections/overview/pull/150, | open, created 2021-01-22T07:07:09Z by abadger: Limiting plugin types 2
19:05:49 <github-linkbot> 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 <gundalow> cybette: you want to #info that
19:06:03 <felixfontein> I guess https://github.com/ansible-collections/overview/pull/150 is the most urgent
19:06:04 <github-linkbot> https://github.com/ansible-collections/overview/pull/150 | open, created 2021-01-22T07:07:09Z by abadger: Limiting plugin types 2
19:06:36 <felixfontein> then we also have today's deadline for new collections in Ansible 3.0.0
19:06:43 <felixfontein> abadger1999: any preference on the order of discussing things?
19:06:59 <cybette> #info Ansible Contributor Summit 2021.03 will be on March 9 (Tuesday)
19:07:19 <abadger1999> I think w must get a decision on whether any new collections are blocking  release.
19:07:23 <abadger1999> So maybe that first.
19:07:45 <cybette> #info add topics for Ansible Contributor Summit here: https://hackmd.io/uZDSLOOdS1Kx0xfZVIATmQ
19:07:50 <abadger1999> Then rule changes in order of whether we think it's necessary to get any of those collections approved
19:08:12 <felixfontein> sounds good to me
19:08:20 <felixfontein> do you want to go through them?
19:09:07 <abadger1999> I can lead but I haven't been part of the reviews themselves.
19:09:39 <abadger1999> We currently have four new collections which are in review.
19:09:53 <felixfontein> #topic Inclusion of collections in Ansible 3.0.0
19:10:15 <abadger1999> First one (by date submitted):  https://github.com/ansible-collections/ansible-inclusion/discussions/3 dellemc.openmanage
19:11:06 <abadger1999> 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 <abadger1999> dmsimard, felixfontein, andersson007_ ^
19:12:30 <felixfontein> 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 <dmsimard> 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 <samccann> from an FQCN perspective... that is one long collection name!
19:14:25 <samccann> oh sorry, ignore me - I was looking at the repo name, not the collection name.. doh!
19:14:33 <felixfontein> hmm I wonder if the namespace name `c` is still open :)
19:14:49 <tadeboro> samccann: Let me introduce you to digitalocean.digitalocean and servicenow.servicenow ;)
19:15:04 <samccann> haha yeah I've seen the likes of that before tadeboro !!
19:15:25 <abadger1999> 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 <felixfontein> for dellemc.openmanage, I think extending the deadline to end of this week is enough
19:16:03 <abadger1999> #info We
19:16:04 <felixfontein> 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 <abadger1999> #undo
19:16:06 <zodbot> Removing item from minutes: INFO by abadger1999 at 19:16:03 : We
19:16:14 <gundalow> 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 <dmsimard> +1 to felixfontein, I believe their v3.0.0 will be sufficient and land in time for inclusion
19:17:04 <abadger1999> 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 <dmsimard> +1
19:17:21 <tadeboro> +1
19:17:22 <felixfontein> +1
19:17:26 <abadger1999> +1
19:17:38 <samccann> is dellemc a 'partner' and are there ramifications to that if it doesn't make it into 3.0 community?
19:17:45 <dericcrago> +1
19:17:47 <cybette> +1
19:17:48 * acozine has an uniformed opinion, abstains
19:18:00 <dmsimard> samccann: dellemc has certified collections though this is not one of them (at least last I checked on AH(
19:18:09 <abadger1999> #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 <samccann> ah thanks dmsimard
19:18:19 * lmodemal abstains
19:18:40 <dmsimard> 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 <abadger1999> 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 <dmsimard> with that in mind, being in one does not qualify for a free pass to the other
19:19:12 <felixfontein> fun fact: installing all collections included in ansible-2.10.6 with `ansible-galaxy collection install` takes 13 minutes
19:19:20 <gundalow> +1
19:19:24 <abadger1999> Second collection: ansible.utils   https://github.com/ansible-collections/ansible-inclusion/discussions/4
19:19:28 <felixfontein> (and for some reason, it also installs kubernetes.core, which isn't part of ansible-2.10.6)
19:19:50 <gundalow> felixfontein: Can you please raise a bug for that in antsibull
19:20:07 <abadger1999> felixfontein: Hmmm.. I hope we don't have a missing dep.  We might need to remove a collection
19:20:08 <tadeboro> 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 <felixfontein> gundalow: as soon as I find out which collection that is, I'll do
19:20:13 <cybette> 10 minutes on topic "Inclusion of collections in 3.0.0", 20 minutes into meeting
19:20:39 <abadger1999> gundalow: we probably need to check that before build time (or maybe check it in the nightly builds)
19:20:40 <felixfontein> ansible.utils is currently missing sanity tests for ansible-base 2.10
19:20:59 <abadger1999> #topic staTus of ansible.utils for ansible 3.0.0
19:21:15 <felixfontein> (and a new release with the review adjustments and changed subplugin directories)
19:21:34 <abadger1999> ganeshrn, pabelanger, felixfontein, tadeboro  ^
19:21:44 <abadger1999> <nod>
19:22:10 <samccann> 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 <abadger1999> 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 <samccann> 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 <tadeboro> IIRC, networking team is working on adding 2.10 sanity tests to Zuul. I do not remember what timeline they set.
19:23:16 <abadger1999> Since ansible-3.0 is based on ansible-base-2.10, it seems pretty bad that those tests aren't running.
19:23:31 <tadeboro> samccann: It is a blocker only if ansible includes 2.0.0 version.
19:23:35 <abadger1999> samccann: I guess we'd have to pin  ansible.netcommon to an old version :-(
19:24:09 <abadger1999> (Not saying it's not a blocker.... just that there is an alternative)
19:24:14 <gundalow> pabelanger: ikhan We are talkign about `ansible.utils`
19:24:23 <dmsimard> are the sanity tests the last item to address ? can we get a commitment to fix it by friday ?
19:24:39 <gundalow> Qalthos: maxamillion FYI ^
19:25:04 <gundalow> I believe pabelanger said he'd be working on sanity test for network collections next week
19:25:25 <abadger1999> Alright... that's probably too late.
19:25:38 <felixfontein> well, that the sanity tests MUST be there has been clear for week now.
19:25:41 <felixfontein> *weeks
19:25:49 <pabelanger> yes, we are adding them now
19:25:53 <abadger1999> So... current estimate.... it would not make the 3.0 deadline.
19:26:09 <abadger1999> Ah... pabelanger , you're a better source of info...
19:26:33 <abadger1999> Is that going to be added by today?  Or if not todqay, can it be added before 2-2?
19:27:11 <pabelanger> we should have it by 2-2, just waiting on code review, jobs to be finished
19:27:45 <pabelanger> 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 <github-linkbot> 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 <felixfontein> 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 <felixfontein> that would allow to get things moving without blocking everything
19:28:15 <pabelanger> I mean, we can just run it locally and share results too
19:29:12 <abadger1999> felixfontein: <nod> 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 <tadeboro> 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 <abadger1999> 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 <felixfontein> I'm happy once sanity tests are properly run, against all necessary Python versions (for the tests where that makes sense)
19:30:30 <cybette> 10 minutes on topic "Status of ansible-utils for ansible 3.0.0", 30 minutes into meeting
19:30:47 <felixfontein> from what pabelanger wrote it sounds like sanity tests could be there by tomorrow, is that correct?
19:31:10 <felixfontein> or how long does running the jobs and reviewing needs?
19:31:46 <pabelanger> we can run sanity now, on the collection and share the results. If that is the hold up
19:31:52 <abadger1999> pabelanger, felixfontein Shall we say submit by Friday just like dellemc.openmanage?
19:31:54 <pabelanger> jobs will be added by 2-2
19:32:40 <felixfontein> does it really need to take until 2-2 to add sanity tests to CI?
19:33:07 <felixfontein> I mean I can also run them locally, that's not really the point
19:33:34 <pabelanger> right, they are passing now, they just are not public tests yet
19:34:21 <abadger1999> It feels like we're talking past each other here...
19:34:36 <gundalow> I'm raising a PR to run sanity on 2.10 via GHA
19:35:44 <felixfontein> 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 <abadger1999> 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 <pabelanger> right, if 2-2 is the deadline, we cna get it done by then
19:36:59 <pabelanger> or it is friday, then we can try
19:37:03 <abadger1999> pabelanger: The deadline is today.
19:37:27 <pabelanger> yah, I don't think we are releasing today
19:37:31 <abadger1999> So we're seeing if we can negotiate an extension.
19:37:34 <pabelanger> we are aiming for friday I think
19:37:53 <abadger1999> Okay... So felixfontein pabelanger Here's my strawman...
19:38:02 <pabelanger> 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 <gundalow> PR with GHA is running: https://github.com/ansible-collections/ansible.utils/pull/39/checks
19:38:42 <samccann> gundalow: for the unwashed masses (aka me) - does that solve the sanity check conundrum (assuming it passes)?
19:38:54 <gundalow> samccann: I think so
19:38:59 <samccann> cool
19:38:59 <gundalow> felixfontein: ?
19:39:05 <felixfontein> gundalow: it does! thanks for the PR :)
19:39:05 <abadger1999> 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 <dmsimard> +1
19:39:17 <felixfontein> abadger1999: +1
19:39:35 <tadeboro> +1
19:39:44 <gundalow> +1
19:39:46 <samccann> 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 <abadger1999> pabelanger: Is that okay with you?  I know ansible.utils underpines changes that you all want to do....
19:40:16 <samccann> 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 <pabelanger> wfm
19:40:32 <abadger1999> samccann: yeah :-(
19:40:37 <samccann> which means that team I think would have to continue bugfixes on older releases for another month maybe?
19:40:58 <samccann> k. just my point being - has a ripple affect into a good 1/2 dozen other collections potentially, maybe more
19:41:09 <cybette> 20 minutes on topic "Status of ansible-utils for ansible 3.0.0", 40 minutes into meeting
19:41:13 <felixfontein> yep, that's why it would be good to have this solved ASAP
19:41:40 <gundalow> ansible.utils Sanity passes on 2.10 via GHA
19:41:45 <abadger1999> #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 <felixfontein> 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 <gundalow> ansible.utils Sanity fails on 2.11 (devel) as the collection doesn't support that version
19:42:17 <abadger1999> #topic inspur.sm status:  https://github.com/ansible-collections/ansible-inclusion/discussions/8
19:42:19 <felixfontein> gundalow: exactly
19:42:20 <gundalow> ansible.utils utils tests are failing on 2.10, not sure why
19:42:28 <felixfontein> gundalow: missing Python dependency
19:42:29 <pabelanger> 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 <abadger1999> #undo
19:42:38 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f94a79a2d50>
19:42:39 <pabelanger> that is blocking the process
19:43:23 <felixfontein> pabelanger: the blocker is that ansible-base 2.10 sanity tests are not run in CI
19:43:43 <abadger1999> 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 <pabelanger> after is fine
19:43:53 <felixfontein> and that some sanity tests for stable-2.9 are not run because you only run the python-3.6 ones
19:43:56 <abadger1999> Cool.
19:44:01 <abadger1999> #topic inspur.sm status:  https://github.com/ansible-collections/ansible-inclusion/discussions/8
19:44:49 <abadger1999> felixfontein, tadeboro, dmsimard: How's this one look?
19:44:51 <tadeboro> 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 <abadger1999> Legal issues seem solved.
19:45:18 <gundalow> Have they added deprecation notices for the non-CRUD modules?
19:45:19 <felixfontein> 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 <gundalow> I've been very impressed with inspur for fixing everything
19:46:12 <felixfontein> yes, definitely
19:46:16 <tadeboro> 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 <felixfontein> especially as it seems to be only one person working on this
19:46:28 <abadger1999> The issue is what?  That it's a thin wrapper around the API?  Which, for end users, means.... not idempotent?
19:47:16 <tadeboro> abadger1999: That collection contained modules such as add_user, del_user, edit_user.
19:47:27 <felixfontein> 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 <abadger1999> Heh :-)
19:47:57 <dmsimard> 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 <abadger1999> <nod>
19:48:11 <tadeboro> 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 <abadger1999> Okay, so it sounds like they're responsive and doing well.. need one more collection release.
19:48:49 <dmsimard> 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 <abadger1999> 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 <felixfontein> +1
19:49:31 <dmsimard> +1
19:49:34 <abadger1999> +1
19:49:35 <samccann> +1
19:49:36 <tadeboro> +1
19:49:46 <lmodemal> +1
19:49:51 <cybette> +1
19:49:58 <abadger1999> #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 <acozine> +1 let's reward responsiveness
19:50:51 <abadger1999> #topic infoblox.nios_modules status https://github.com/ansible-collections/ansible-inclusion/discussions/11
19:51:03 <gundalow> (late +1)
19:51:13 <cybette> 50 minutes in the meeting! moving along great!
19:51:15 <felixfontein> infoblox.nios_modules came very late to the party
19:51:51 <felixfontein> the application officially was made 2 days ago (https://github.com/ansible-collections/ansible-inclusion/discussions/11#discussioncomment-308541)
19:51:52 <dmsimard> 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 <abadger1999> Yeah... the others were all in December.  this one was 8 days ago.
19:52:10 <felixfontein> also, I'm not sure how familiar they are with Ansible
19:52:41 <felixfontein> 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 <abadger1999> <nod>
19:53:52 <felixfontein> 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 <abadger1999> 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 <abadger1999> 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 <felixfontein> 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 <dmsimard> right -- I don't see this as a blocker to Ansible 3.0
19:55:15 <felixfontein> if there aren't enough positive reviews until Friday, I guess they have to wait
19:55:46 <tadeboro> We can delay until Friday, but I do not see them making it.
19:55:55 <felixfontein> 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 <cybette> yeah we have stated since early December (in multiple Bullhorn issues) that collections should be submitted as early as possible
19:56:03 <felixfontein> tadeboro: I agree
19:56:03 <abadger1999> 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 <dmsimard> abadger1999: I can take it
19:56:18 <tadeboro> But then again, IIRC, this is a certified collection (if this makes any difference).
19:56:28 <dmsimard> I'm the only one who has reviewed it so far
19:56:35 <abadger1999> Okay cool.
19:56:45 <felixfontein> 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 <felixfontein> I don't think 'certified' makes any difference
19:57:08 <tadeboro> 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 <felixfontein> from what I've seen certified collections doing so far
19:57:13 <samccann> 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 <samccann> (in Ansible 3)
19:57:45 <abadger1999> 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 <felixfontein> 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 <felixfontein> +1
19:58:08 <abadger1999> +1
19:58:09 <tadeboro> +1
19:58:14 <cybette> +1
19:58:23 <dmsimard> ok ? I guess :D
19:58:37 <gundalow> 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 <samccann> 0.  I worry about duplicated modules in Ansible 3.x
19:58:51 <acozine> I thought dmsimard already reviewed this collection?
19:58:58 <acozine> but nobody else has?
19:59:01 <felixfontein> gundalow: they have. unfortunately they never really made an effort from my POV
19:59:03 <acozine> did I misinterpret?
19:59:04 <samccann> my preference would be to see them removed from c.g at the same time (aka ansible 4)
19:59:12 <abadger1999> I guess it's more like.... guiding the review to approval?
19:59:22 <gundalow> felixfontein: That's my impression as well
19:59:49 <abadger1999> 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 <felixfontein> gundalow: otherwise we could have just grandfathered their collection in as community.postgresql, community.docker, cisco.nso etc.
20:00:21 <felixfontein> if they have everything done by Friday, I'll happily review it
20:00:26 <abadger1999> #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 <abadger1999> #undo
20:00:32 <zodbot> 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 <cybette> 10 minutes on topic "infoblox.nios_modules status", 1 hour into meeting
20:00:46 <abadger1999> #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 <abadger1999> #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 <felixfontein> and I guess new applications won't be accepted anymore?
20:02:06 <felixfontein> (at least not for 3.0.0 :) )
20:02:07 <abadger1999> felixfontein: Okay, do you want to take the next section, new guidelines?
20:02:10 <dmsimard> new applications would target 4.0
20:02:14 <felixfontein> abadger1999: sounds good
20:02:29 <felixfontein> #topic Limiting plugin types (https://github.com/ansible-collections/overview/pull/150)
20:02:30 <github-linkbot> https://github.com/ansible-collections/overview/pull/150) | open, created 2021-01-22T07:07:09Z by abadger: Limiting plugin types 2
20:02:43 <tadeboro> Who will inform the maintainers about today's decisions?
20:02:52 <felixfontein> this is an updated proposal by abadger1999 about limiting plugin types
20:02:59 <abadger1999> tadeboro: I'll take that (by posting a comment to each discussion)
20:03:06 <felixfontein> 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 <tadeboro> abadger1999: Thank you!
20:03:51 <felixfontein> 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 <felixfontein> abadger1999: thanks!
20:04:18 <felixfontein> (of course, next to the subdirectories supported by ansible-base/-core)
20:04:56 <felixfontein> 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 <felixfontein> comments/questions on this proposal?
20:05:17 <abadger1999> ganeshrn / pabelanger and sivel / nitzmahone: This is the proposal as a result of the discussions we had last week.
20:06:05 <abadger1999> I think it satisfies everything that you all brought up about the subdirs of the plugins directory;
20:06:20 <felixfontein> 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 <tadeboro> I like the small number of added directories. So +1 from me.
20:07:37 <nitzmahone> I'm good with that- lemme poke Matt C for the ansible-test/sanity side of things
20:07:47 <abadger1999> I like it but I'll wait to make sure nitzmahone looks before registering my +1
20:08:04 <acozine> 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 <abadger1999> acozine: ganeshrn said his team is moving those directories under plugins/sub_plugins/
20:08:43 <acozine> ah, thanks!
20:08:56 <abadger1999> Thanks for checking :-)
20:09:48 <acozine> looks like a clean, clear, easily understood policy to me, +1
20:10:35 <nitzmahone> Matt C is looking at it right now WRT ansible-test et al
20:10:41 <abadger1999> Cool.
20:11:24 <nitzmahone> 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 <cybette> 10 minutes on topic "Limiting plugin types", 1H12M into meeting
20:12:20 <mattclay> Why are these plugin types explicitly listed? ``doc_fragments``, ``modules``, ``module_utils``, ``terminal``
20:12:36 <abadger1999> mattclay: because they aren't listed on the docs.a.c page
20:12:39 <mattclay> They're already listed in the referenced source file: https://github.com/ansible/ansible/blob/devel/lib/ansible/plugins/loader.py
20:12:58 <abadger1999> 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 <nitzmahone> +1, was gonna say I think that's an oversight on our part ;)
20:13:21 <felixfontein> 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 <abadger1999> yeah
20:13:43 <mattclay> Yeah, the docs should be updated to match the source so we don't need to have a separate list.
20:13:52 <briantist> what is `plugin_utils` for exactly?
20:14:05 * lmodemal Have to leave this meeting early. Good meeting :)
20:14:11 <felixfontein> 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 <felixfontein> bye lmodemal!
20:14:47 <nitzmahone> 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 <briantist> `module_utils` can/is can be used for plugins too right? Is this more of a logical distinction then?
20:15:01 <tadeboro> briantist: For code, shared by inventory plugins, filters, ...
20:15:02 <briantist> Ah ok for testing too
20:15:13 <felixfontein> briantist: it can, but if you import things from ansible that modules cannot import, the sanity checks will scream at you ;)
20:15:15 <mattclay> Are `sub_plugins` always going to be controller-only?
20:15:38 <bcoca> until someone wants to use em in module
20:15:49 <nitzmahone> All current known usages are, but may not always be Python
20:15:49 <felixfontein> mattclay: assuming nobody writes a crazy action plugin that pushes them to the remote, yes
20:16:06 <nitzmahone> They can be loaded as resources
20:16:54 <mattclay> If `sub_plugins` are intended to be controller-only, then the docs should mention that as well.
20:17:31 <abadger1999> 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 <nitzmahone> 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 <abadger1999> mattclay: ^
20:18:07 <nitzmahone> (eg an ansible_test_config section in metadata or something)
20:18:11 <felixfontein> most sanity tests that apply to all existing plugin types are already run for arbitrary directories
20:18:32 <nitzmahone> Yeah, that works for now as well, but could be problematic in the future
20:19:19 <mattclay> So ansible-doc won't work on sub_plugins, right?
20:19:26 <abadger1999> Correct.
20:19:29 <felixfontein> yes
20:19:47 <nitzmahone> Not to say that couldn't be addressed in the future either, but it's not a big issue ATM
20:20:18 <mattclay> It would be easy to add a sanity test to check for these rules.
20:20:32 <nitzmahone> (goes back to that whole sidecar docs/metadata thing)
20:21:37 <mattclay> I'm not sure `sub_plugins` is the best name, but I haven't thought of anything better.
20:21:50 <abadger1999> mattclay: +1
20:21:58 <abadger1999> and we kind of have to make a decision now.
20:22:11 <cybette> 20 minutes on topic "Limiting plugin types", 1H22M into meeting
20:22:15 <abadger1999> So... perfect is the enemy of the good.
20:22:16 <nitzmahone> Hrm- `user_plugins`, `custom_plugins`?
20:22:21 <mattclay> Did the name already go through bikeshedding?
20:22:27 <abadger1999> yes-ish
20:22:42 <abadger1999> and ganeshrn doesn't appear to be around so I'd rather not change it out from under him.
20:22:44 <nitzmahone> I don't love it either, but I don't have a really strong opinion :)
20:22:44 <mattclay> nitzmahone: I like both of those better than `sub_plugins`
20:23:02 <abadger1999> (even though I like custom_plugins better too)
20:23:05 <dmsimard> naming things is hard :)
20:23:11 <bcoca> plugins_shared .. they are not really plugins but shared code for em
20:23:20 <nitzmahone> Well, subplugins are
20:23:20 <mattclay> abadger1999: What's the reason for needing to decide now?
20:23:42 <bcoca> ^ publishing the networking collections that use this
20:23:44 <felixfontein> mattclay: ansible.utils and ansible.netcommon need to be released the next days with these changes
20:23:47 <nitzmahone> Maybe just say we're good with everything, final naming TBD
20:24:06 <bcoca> nitzmahone: the issue is that naming affects import statements aka code
20:24:10 <felixfontein> so the name should better be known today, otherwise the schedule blows up :)
20:24:16 <abadger1999> 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 <abadger1999> which is kind of unfair to them
20:25:51 <abadger1999> 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 <abadger1999> (other issues or major bikeshed are okay)
20:26:28 <nitzmahone> 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 <bcoca> plugins/_shared
20:26:46 <felixfontein> abadger1999: I added a suggestion to change 'modules' to 'action plugins', since modules cannot access that folder
20:27:11 <bcoca> felixfontein: what do we do with action plugins then?
20:27:26 <felixfontein> bcoca: huh?
20:27:35 <felixfontein> bcoca: I'm talking about https://github.com/ansible-collections/overview/pull/150#discussion_r565610306
20:27:36 <bcoca> we already have 'action' plugins
20:27:43 <abadger1999> felixfontein: Merged
20:28:02 <abadger1999> 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 <nitzmahone> bcoca: this is about the text of the proposal,
20:28:27 <felixfontein> maybe we should just say plugins instead of action plugins, since lookups can also use them
20:28:35 <nitzmahone> (the fact that most things under `sub_plugins` are loaded by actions, not modules)
20:28:43 <bcoca> and tests/inventory/etc ..
20:28:44 <felixfontein> (I think I remember that ansible.utils has lookups which load these as well)
20:28:45 <mattclay> felixfontein: Or perhaps `non-module` plugins would be more accurate.
20:28:59 <felixfontein> mattclay: yes, that would be the unified approach :)
20:29:08 <bcoca> its really  local vs remote
20:29:38 <abadger1999> `: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 <bcoca> module_utils/modules are usable for remote code (as well as local, but not main prupose)
20:30:26 <bcoca> its that what i find confusing, 'managed' or 'used' thought you were introducing new 'action plugin' type
20:30:27 <abadger1999> VOTE: Approve https://github.com/ansible-collections/overview/pull/150 (Update the directories allowed in plugins/ )
20:30:48 <abadger1999> +1
20:30:58 <felixfontein> +1 both for the current version and mattclay's suggestion
20:30:59 <nitzmahone> +1 (with reservation on minor naming bikeshed)
20:31:04 <acozine> +1
20:31:07 <tadeboro> +1
20:31:22 <dmsimard> +1
20:31:31 <briantist> +1
20:31:35 <cybette> +1
20:31:59 <abadger1999> #info https://github.com/ansible-collections/overview/pull/150 (Update the directories allowed in plugins/ ) approved
20:32:25 <mattclay> I'd also suggest that we add 'or module_utils' to `For shared code which is only used controller-side, not in modules`
20:32:39 <cybette> 30 min on topic "Limiting plugin types", 1H 32M into meeting
20:34:13 <abadger1999> I think both of those could fall under clarifications.  Let's do those either outside of the meeting or next time if they seem like they become more than clarification.
20:35:01 <felixfontein> +1
20:36:32 <abadger1999> felixfontein: Want to choose the next guideline to discuss?
20:37:20 <felixfontein> #topic Require that regular CI runs (nightly, weekly, or inbetween) are actually looked at and not just ignored (https://github.com/ansible/community/issues/539#issuecomment-763981413)
20:37:55 <abadger1999> I'm +1.... I feel like this was implied by the fact that the CI  runs were required.
20:37:58 <felixfontein> it's nice that we require regular CI runs (at least once per week), but if some collection maintainers never look at them, this is kind of a waste
20:38:04 <felixfontein> I thought so too
20:38:18 <felixfontein> until the debate at last week's meeting
20:38:22 <gundalow> aye :(
20:38:45 <gundalow> things changing over ------> here
20:38:45 <gundalow> can break your thing
20:39:08 <felixfontein> I mean it's ok if not every nightly run is checked. sometimes people have weekends, vacation, ...
20:39:16 <felixfontein> but just ignoring all of them is not acceptable IMO
20:39:42 <nitzmahone> Would it be simpler to just say that a collection that doesn't have a CI run newer than $interval won't be included?
20:39:43 <felixfontein> that's why I put another "reguar" in the proposal: "The results from the regular CI runs MUST be checked regularly."
20:40:06 <felixfontein> nitzmahone: we already require that
20:40:12 <nitzmahone> If someone wants to let it rot until a week or so before a snapshot, do we really care so long as it's working before it gets grabbed?
20:40:14 <felixfontein> nitzmahone: doesn't mean anyone actually looks at these runs
20:40:22 <dmsimard> Not easy to enforce though we can refer to the history if there are doubts
20:40:41 <dmsimard> for example if PRs are being merged despite CI failures
20:41:19 <felixfontein> sometimes that's necessary, but it's a good idea to always mention that next to the merge :)
20:41:33 <abadger1999> dmsimard: this is intended  to capture a collection that's not changing frequently.
20:41:42 <maxamillion> gundalow: sorry, I've been in meetings all day .. what are were you trying to highlight FYI for earlier? something about ansible.utils and testing?
20:42:45 <felixfontein> this is another point that's still open for ansible.utils, I think
20:42:55 <felixfontein> (and probably most other collections in Ansible that use zuul for testing)
20:43:15 <felixfontein> as far as I understood there are no regular runs, it only runs on commits/PRs
20:43:27 <abadger1999> maxamillion: I think it's okay... we were considering whether ansible.utils blocks ansible-3 and whether it can be ready before the deadline (we extended the deadline for ready-for-final-review until Friday)
20:43:41 <abadger1999> mattclay: pabelanger said it could be ready for final review by friday.
20:43:50 <abadger1999> mattclay: sorry... that was for maxamillion
20:44:37 <abadger1999> felixfontein: My understanding from pabelanger was that there are regular runs but at the moment they don't have anyone assigned to look at them and fix any reported breakage.
20:44:54 <maxamillion> abadger1999: rgr that
20:44:57 <felixfontein> abadger1999: I understood from pabelanger that they disabled the regular runs
20:45:11 <maxamillion> I'm not really involved with ansible.utils at all currently :)
20:45:13 <felixfontein> but maybe I understood it wrong
20:45:27 <felixfontein> maxamillion: does ansible.posix have regular CI runs?
20:45:28 <abadger1999> I think he was saying "sincewe ignore the output, will you let us disable these regular runs"
20:45:38 <maxamillion> felixfontein: yes
20:45:43 <felixfontein> maxamillion: +1 :)
20:45:58 <maxamillion> felixfontein: well ... we CI every PR, but we're not actively CI'ing the whole thing on a time interval that I know of
20:46:12 <felixfontein> maxamillion: hmm, so if no PR happens for two months, no CI will run?
20:46:27 <maxamillion> felixfontein: to the best of my knowledge, yes
20:46:38 <felixfontein> maxamillion: in that case, you do not satisfy the requirements
20:46:45 <maxamillion> felixfontein: but it won't merge without a fresh ci run because it's gated by zuul
20:47:09 <abadger1999> maxamillion: ah... yeah, that's what we're getting at.  (because ansible-test updates and we release ansible packages every three weeks, we have a rule that tests must be run at least once a week... and we expect that someone would then fix any new breakage discovered that way)
20:47:12 <gundalow> maxamillion: so the issue here is. What if ansible-core (especially devel) gets updated and breaks your testing
20:47:20 <felixfontein> but the collection might have stopped working two months ago, and nobody noticed, since no PR was created / modified
20:47:45 <cybette> 10 min on topic "Checking results of regular CI runs", 1H 47M into meeting
20:48:15 <maxamillion> abadger1999: ahhh ok
20:48:26 <maxamillion> gundalow: we wouldn't know
20:48:30 <maxamillion> gundalow: at least not now
20:48:44 <gundalow> maxamillion: aye, hence wanting regular runs
20:48:57 <abadger1999> Maybe we should vote on this change... it borders on clarification (the regular runs rule already exists) but does add a new explicit requirement for maintainers to care about the output of the regular runs.
20:48:58 <maxamillion> gundalow: I don't even know how the Azure pipeline stuff works, someone else did that migration so I'm not sure how to kick regular runs
20:49:13 <abadger1999> Then we can talk to any collections that aren't doing that later.
20:49:16 <gundalow> This is really important for `devel` where we will continue to be adding & updating ansible-test sanity
20:49:52 <gundalow> maxamillion: AZP does a nightly run at 0900 UTC, https://github.com/ansible-collections/ansible.posix/blob/main/.azure-pipelines/azure-pipelines.yml#L15-L22
20:50:19 <felixfontein> abadger1999: +1
20:50:38 <maxamillion> gundalow: oh ok, so ... ansible.posix should be in that, no?
20:51:00 <abadger1999> VOTE: Require that regular CI runs (nightly, weekly, or inbetween) are actually looked at and not just ignored (https://github.com/ansible/community/issues/539#issuecomment-763981413)
20:51:05 <abadger1999> +1
20:51:06 <gundalow> +1
20:51:07 <felixfontein> +1
20:51:08 <maxamillion> gundalow: errrr, I mean that should add the required criteria for ansible.posix to be included
20:51:09 * gundalow -> afk
20:51:19 <gundalow> maxamillion: I think ansible.posix is OK
20:51:26 <felixfontein> and it's already included ;)
20:51:28 <tadeboro> +1
20:51:30 <cybette> +1
20:51:33 <pabelanger> -1
20:51:56 <briantist> +1
20:52:44 <dmsimard> +1 though I regret that it needs to be clarified
20:53:05 <abadger1999> #info Approved: Require that regular CI runs (nightly, weekly, or inbetween) are actually looked at and not just ignored (https://github.com/ansible/community/issues/539#issuecomment-763981413)
20:53:20 <felixfontein> I'll create a PR to add that later
20:54:09 <felixfontein> ok. considering that we're close to two hours, I don't think we should start new topics
20:54:39 <felixfontein> the currently open requirement updates are: a) https://github.com/ansible-collections/overview/pull/151, b) https://github.com/ansible/community/issues/539#issuecomment-766905372
20:54:40 <github-linkbot> https://github.com/ansible-collections/overview/pull/151, | open, created 2021-01-25T12:48:11Z by Ompragash: New Policy Regarding Python Compatibility for Collections
20:54:45 <dmsimard> +1, unless someone has something that can't wait until next meeting
20:54:51 <felixfontein> please take a look at them and comment if necessary
20:54:54 <felixfontein> #topic open floor
20:55:04 <felixfontein> now's the place for coming up with topics that we missed :)
20:55:08 <dmsimard> FYI I also opened https://github.com/ansible-collections/overview/pull/152 about clarifying doc requirements (from a past meeting)
20:55:09 <github-linkbot> https://github.com/ansible-collections/overview/pull/152 | open, created 2021-01-27T20:17:20Z by dmsimard: Improve clarity of the documentation requirements
20:56:23 <dmsimard> it can certainly wait for next meeting but feel free to review
20:57:30 <felixfontein> I'd add a 'strongly' in one case, but besides that it looks good! :)
20:57:48 <felixfontein> can you add it to the agenda (to increase visibility)?
20:58:02 <dmsimard> will do
20:58:38 <abadger1999> I'm going to work up a schedule for ansible-4 this week.  (and probably also some competing proposals for the ansible-5 schedule which we can mull over)
20:58:56 <felixfontein> sounds good!
20:59:26 <felixfontein> here's the PR for the regular CI appendum: https://github.com/ansible-collections/overview/pull/153/files
21:00:28 <abadger1999> Looks like what we approved ;-)
21:00:40 <felixfontein> yep, I copied it over from the agenda comment ;)
21:00:45 <felixfontein> #endmeeting