18:00:13 <felixfontein> #startmeeting Ansible Community Meeting
18:00:13 <zodbot> Meeting started Wed May  4 18:00:13 2022 UTC.
18:00:13 <zodbot> This meeting is logged and archived in a public location.
18:00:13 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:13 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:13 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:13 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/645
18:00:13 <felixfontein> acozine andersson007_ baptistemm bcoca briantist cyberpear cybette dericcrago dmsimard felixfontein geerlingguy gundalow gwmngilfen ikhan_ jillr jtanner lmodemal misc nitzmahone resmo samccann tadeboro cidrblock thaumos zbr: ping!
18:00:17 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics
18:00:19 <dmsimard> o/
18:00:20 <felixfontein> #topic Updates
18:00:22 <felixfontein> hellooooooo o/
18:00:28 <felixfontein> #chair dmsimard
18:00:28 <zodbot> Current chairs: dmsimard felixfontein
18:00:36 <andersson007_> o/
18:00:42 * bcoca does quick wave and goes back to meeting
18:00:48 <dmsimard> #info ansible 5.7.1 has been released: https://groups.google.com/g/ansible-announce/c/GmOhXTtmj_w
18:00:50 <felixfontein> #chair andersson007_
18:00:50 <zodbot> Current chairs: andersson007_ dmsimard felixfontein
18:00:51 <resmo> o/
18:00:55 * felixfontein waves at bcoca!
18:00:58 <felixfontein> #chair resmo
18:00:58 <zodbot> Current chairs: andersson007_ dmsimard felixfontein resmo
18:01:01 <andersson007_> #info Feedback wanted on the [What to do with a lack of collection inclusion reviews](https://github.com/ansible-community/community-topics/issues/97) community topic. The backlog of submitted collections is growing, the number of volunteers is not:) How can we fix the situation? See the topic for details.
18:01:08 <mgraves[m]> o/
18:01:13 <samccann> \o
18:01:15 <gundalow> o/
18:01:16 <jillr> o/
18:01:18 <felixfontein> andersson007_: will you mention the vmware collection?
18:01:25 <felixfontein> #chair mgraves[m] samccann gundalow jillr
18:01:25 <zodbot> Current chairs: andersson007_ dmsimard felixfontein gundalow jillr mgraves[m] resmo samccann
18:01:28 <cybette> o/
18:01:40 <felixfontein> #chair cybette
18:01:40 <zodbot> Current chairs: andersson007_ cybette dmsimard felixfontein gundalow jillr mgraves[m] resmo samccann
18:01:41 <andersson007_> felixfontein: was not going:)
18:01:54 <felixfontein> ok
18:02:08 <andersson007_> i reviewed resmo's one yesterday
18:02:11 <felixfontein> #info Active vote: include vmware.vmware_rest into Ansible (https://github.com/ansible-community/community-topics/issues/99)
18:02:40 <andersson007_> ah, stop
18:02:55 <andersson007_> there will not be an active vote
18:03:07 <andersson007_> we use the new approach there
18:03:11 <felixfontein> oh, why?
18:03:17 <felixfontein> don't we need to vote on every inclusion request?
18:03:27 <andersson007_> by default it'll get merged  11th on May 2022
18:03:41 <andersson007_> felixfontein: no:) we voted for that:)
18:03:54 * felixfontein is getting old :D
18:04:00 <gundalow> very meta :)
18:04:00 <andersson007_> there was a topic and a pr:)
18:04:11 <cybette> #info please take the Ansible Contributor Survey (if you haven't already). Thanks! https://www.surveymonkey.co.uk/r/TD328PF
18:04:42 <andersson007_> when there are 2 SC reviews and approvals, we create a topic and set up a date
18:05:14 <andersson007_> if no concerns are raised, the collection will get included automatically
18:05:22 <andersson007_> will be considered, i'd say
18:05:49 <andersson007_> so for vmware_rest it'll be on 11th of May
18:06:18 <felixfontein> #undu
18:06:20 <felixfontein> #undo
18:06:20 <zodbot> Removing item from minutes: INFO by cybette at 18:04:11 : please take the Ansible Contributor Survey (if you haven't already). Thanks! https://www.surveymonkey.co.uk/r/TD328PF
18:06:21 <felixfontein> #undo
18:06:21 <zodbot> Removing item from minutes: INFO by felixfontein at 18:02:11 : Active vote: include vmware.vmware_rest into Ansible (https://github.com/ansible-community/community-topics/issues/99)
18:06:30 <felixfontein> cybette: sorry, had to undo your's too to undo mine
18:06:43 <felixfontein> cybette: can you repost yours?
18:07:11 <cybette> #info please take the Ansible Contributor Survey (if you haven't already). Thanks! https://www.surveymonkey.co.uk/r/TD328PF
18:07:14 <cybette> felixfontein: no problem :)
18:07:19 <andersson007_> in short, the new inclusion process is described in https://docs.ansible.com/ansible/devel/community/steering/community_steering_committee.html#collection-inclusion-requests-workflow
18:07:21 <andersson007_> :)
18:08:01 <felixfontein> #info We have some problems with collections included in Ansible, please take a look at the related discussion topics: https://github.com/ansible-community/community-topics/issues/96 https://github.com/ansible-community/community-topics/issues/94
18:10:00 <dmsimard> ^ It turns out that a lot of collections have sanity test failures, we won't have all of them fixed by the time we release 6.0.0a2 but I would like to get the number down drastically by the time ansible 6 is out
18:10:29 <felixfontein> one thing I'd like to discuss today is related to these: what should we do with collections that screw up, either due to being broken (as fortios), having too strict dependencies that limit other collections (community.okd), or don't pass sanity tests that we require them to?
18:11:17 <felixfontein> (the third category is definitely not as bad as the first two :) )
18:11:41 <dmsimard> I wanna say in terms of volume the number of failed sanity tests is what concerns me the most -- in fact, the majority of the collections are not passing
18:12:27 <dmsimard> I will try to create issues in the respective collections' repositories after 6.0.0a2 is out so they are at least aware
18:12:30 <felixfontein> in some cases this is likely caused by stable-2.13 not being used in CI right now
18:12:42 <dmsimard> but if there are so many, it could mean they are not running at all
18:13:01 <andersson007_> i created ~25 issues about adding stable-2.13
18:13:25 <andersson007_> at least 1/3 has been fixed
18:13:48 <felixfontein> I think it would be good to have an 'early warning' system where we find out about such problems ahead of releases, and not on the day of a release
18:14:00 <felixfontein> (which is why I created https://github.com/ansible-community/community-topics/issues/96 :) )
18:14:14 <andersson007_> i'm going to create a list of collections in ~3 weeks where there were no responces
18:14:51 <jtanner> you still have to decide what to do if the maintainer(s) simply won't or refuse to fix the issues
18:14:51 <resmo> just a side note: I noticed github scheduled ci workflow puases after some time (if there was no commits) so probably they aren't aware of it
18:15:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:03 <dmsimard> felixfontein: +1 for #96, we should have been doing it proactively sooner
18:15:05 <felixfontein> jtanner: indeed, we have to!
18:15:21 <andersson007_> 60 days
18:15:35 <felixfontein> resmo: that is indeed a problem, usually the person who set up the workflow gets informed, but nobody else
18:15:50 <felixfontein> GHA is unfortunately pretty spartan w.r.t. notifications
18:16:51 * dmsimard pictures github kicking people into a pit
18:16:57 <felixfontein> resmo: in any case, if we have a system where we notice that collections stop passing sanity tests, we can create issues in these repos so folks will be aware that something isn't right
18:17:12 <resmo> felixfontein, agreed
18:17:27 <felixfontein> dmsimard: hmm, I'm more thinking about the meaning "very, very basic" than "kicking ass" :)
18:17:43 <gundalow> Taking a step back. I wonder if we need to change (or add) where tests are done
18:17:43 <gundalow> For example, should the part of the upload into Galaxy(NG) run `ansible-test sanity` against all ansible-core versions the collection supports (defined in `meta/runtime.yml`)
18:18:34 <andersson007_> if there's no releases?
18:18:35 <felixfontein> isn't AH doing something like that?
18:18:43 <felixfontein> (at least for one version)
18:18:46 <resmo> AH?
18:18:51 <felixfontein> RH's automation hub
18:18:57 <gundalow> AH = Automation Hub = GalaxyNG
18:19:10 <felixfontein> I've seen the abbreviation 'AH' so often I started using it myself, despite never having used that product ;)
18:19:42 <gundalow> I'm sure jtanner can confirm the details, though I believe galaxy-importer runs some tests, though only a hand full of things are treated as fatal
18:19:49 <acozine> o/
18:19:57 <acozine> sorry I'm. late, dentist this AM
18:19:58 <dmsimard> https://github.com/ansible-community/antsibull/pull/419 is what I've used to run sanity tests for every included collections, it could potentially live elsewhere too but once we have something like it we can run it on a regular basis which would be a great improvement over the nothing that we have
18:20:02 <felixfontein> #chair acozine
18:20:02 <zodbot> Current chairs: acozine andersson007_ cybette dmsimard felixfontein gundalow jillr mgraves[m] resmo samccann
18:20:06 <felixfontein> #chair jtanner
18:20:06 <zodbot> Current chairs: acozine andersson007_ cybette dmsimard felixfontein gundalow jillr jtanner mgraves[m] resmo samccann
18:20:49 <jtanner> https://github.com/ansible/galaxy_ng/blob/master/openshift/clowder/clowd-app.yaml#L42 --> https://github.com/ansible/galaxy-importer/blob/3cf251a06184cd16ea8ddc604694e4d327e6efe1/galaxy_importer/ansible_test/runners/local_ansible_test.py#L50-L56
18:21:18 <dmsimard> what's --failure-ok ?
18:21:22 <dmsimard> it means it's non-fatal ?
18:21:46 <felixfontein> --failure-ok          exit successfully on failed tests after saving results
18:22:09 <andersson007_> to run sanity tests somewhere independently from the collections themselves would be great (+ maybe a dashboard)
18:22:18 <dmsimard> andersson007_: very doable
18:22:37 <andersson007_> 👍
18:22:47 <jtanner> https://github.com/ansible/ansible/blob/5c2d830dea986a8c7bd8c286b86bdce326cd7eb1/test/lib/ansible_test/_internal/commands/sanity/__init__.py#L297-L304
18:23:09 <dmsimard> jtanner: I didn't ask so much but thanks :D
18:23:17 <resmo> andersson007_, +1
18:24:53 <felixfontein> what do we do when collections don't (try or manage to) fix issues, say sanity failures, dependency violations, or things like syntax errors?
18:25:05 <jtanner> i think failure-ok was probably added to not be so hard on the partners, but i don't know the history
18:25:45 <acozine> felixfontein: call for new maintainers, then put the collection on a "watch list" for removal, maybe?
18:26:06 <felixfontein> acozine: we can only call for new maintainers if we have access (i.e. it lives in gh.com/ansible-collections)
18:26:14 <resmo> watch list --> call it "hot seat" ;)
18:26:21 <acozine> heh
18:26:23 <felixfontein> resmo: +1 :)
18:26:25 <andersson007_> felixfontein: kick them out, i guess (of course if there are a few sanity errors that i feel confident to fix without breaking something, i'd be always happy to help)
18:26:44 <felixfontein> I guess it should be levelled and depend on the severity of the problem
18:26:51 <andersson007_> we have the removal process now, thank you!
18:26:57 <jtanner> you are still allowing 'broken" collections into the distro if they're not immediately purged or fixed
18:27:19 <jtanner> you should have release notes with big red warnings: "These collections are known to be BAD ..."
18:27:22 <dmsimard> felixfontein: there are requirements and standards to which we ask the included collections to respect -- if the maintainers are aware and the situation is not addressed it is no less than grounds for removal
18:27:30 <acozine> felixfontein: well, we can still advertise "hey this collection is not being maintained" which might bring it to the attention of the company/group/people even if the collection repo is hosted elsewehre
18:27:38 <felixfontein> jtanner: so far we only had community.kubevirt that was fully broken, but we cannot remove it from an existing major version if we want to avoid breaking changes
18:28:35 <felixfontein> acozine: if we consider a collection unmaintained we alreayd have a procedure for that, which includes announcing that in various places (changelog and bullhorn)
18:29:09 <acozine> true
18:29:41 <acozine> I was thinking of the situation you're talking about being a kind of pre-step, were you thinking of a different situation?
18:29:44 <felixfontein> having something broken isn't great, but I think worse is if one collection forces another collection to be hold back due to dependency problems
18:30:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:06 <felixfontein> like community.okd currently forcing that an older version of kubernetes.core has to be shipped in Ansible 6
18:30:12 * resmo is leaving --> kids bed
18:30:21 <felixfontein> bye resmo! thanks for being here!
18:30:24 <felixfontein> #unchair resmo
18:30:24 <zodbot> Current chairs: acozine andersson007_ cybette dmsimard felixfontein gundalow jillr jtanner mgraves[m] samccann
18:30:55 <andersson007_> bye resmo!
18:31:34 <acozine> ciao resme
18:31:37 <acozine> * ciao resmo
18:32:26 <felixfontein> what do you think about having a new rule on dependent collections? like a) if you depend on a major version, you have to accept that you might get removed for the next major Ansible release if you don't manage to release a version in time which works with the latest major version of the collection you dependent on, and b) if you have a more tight dependency, then your collection must live
18:32:32 <felixfontein> in gh.com/ansible-collections and we must be able to make releases (so we can forcefully loosen the dependency and make a new release), or the same team must maintain both collections
18:32:50 <felixfontein> a) aims at collections depending on ansible.netcommon or ansible.utils (all network collections do that)
18:33:06 <felixfontein> b) aims at collections such as kubernetes.core and community.okd, or amazon.aws and community.aws
18:34:03 <dmsimard> I think dependant collections are well worth discussing though I must point out that community.okd is in currently the process of fixing the dependency such that it is bound to be resolved by the time ansible 6 is out -- this would be a different discussion if this wasn't the case
18:34:30 <felixfontein> so for example if community.okd would simply ignore this problem and we wouldn't be able to update kubernetes.core for half a year, we could simply add a commit which loosens the dependency and release their collection, even ignoring that CI doesn't pass for anything
18:34:42 <felixfontein> (not that we really want to do that, but we could, and they have to accept that)
18:34:58 <acozine> seems okay to me - "if. your collection depends on. another collection you have some special responsibilities"
18:35:24 <felixfontein> dmsimard: I know that community.okd should be fixed soon, I mainly want to use them as a theoretical example to flesh out what we could (or would have to) do if they'd ignore the problem
18:35:37 <mgraves[m]> in the case of community.okd, that repo is used to generate the redhat.openshift collection, so there is no way we would be able to agree to forcing a release
18:36:16 <felixfontein> for a), if some network collection doesn't want to work with ansible.netcommon 4.0.0, which we want to include for Ansible 7, we'd kick that network collection out instead (without deprecation period)
18:36:44 <dmsimard> felixfontein: yeah that's fine, like I said it's worth doing the exercise of "what if"
18:36:54 <jillr> yeah, k8s.core and c.okd are a specific case where there is very active and engaged maintenance. for anything else it's mostly hypothetical
18:37:38 <felixfontein> mgraves[m]: I don't think anyone wants it, and I guess that it won't come that far anyway since RH 'owns' both collections
18:38:13 <jillr> the okd collection isn't even in an ansible namespace on github, so this is academic anyway
18:38:21 <felixfontein> mgraves[m]: but if there would be community.randomothercollection that puts such a restriction on kubernetes.core, we might have to do that if they restrict kubernetes.core for a longer time
18:38:22 <dmsimard> In terms of outcome, it is highly dependant on a number of factors -- some possibilities I see: 1) we pin k8s.core such that okd still works (and live without k8s.core updates for the duration of ansible 6), 2) we leave k8s.core unpinned and ship a broken okd, 3) okd is removed
18:38:43 <felixfontein> jillr: it used to be :)
18:39:09 <dmsimard> jillr: the part about the namespace is mostly about last resort of the community working group to "step in" I think
18:39:31 <felixfontein> dmsimard: I think we have to pin k8s.core in that case
18:39:43 <jillr> given that each case this comes up will likely be full of unique criteria (who manages it, whhat does it block, etc) is it worth havng a blanket policy?
18:39:56 <felixfontein> also 2) doesn't only mean that okd is broken ,but that Ansible in total is broken. you won't be able to make a EE with Ansible then.
18:40:39 <felixfontein> jillr: if you don't mind that some random collection you've never heard of ensures that your collection cannot have updates in an Ansible major release, then we don't need a policy :)
18:41:12 <dmsimard> felixfontein: we already have some criteria about dependencies in https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst#galaxyyml -- perhaps this could use an extra bullet point or two
18:41:15 <jillr> I would assume it would be evaluated in each case.  can such a policy be written that covers all possibilities?
18:41:28 <samccann> I think if we plan on removing a collection, or pinning some collection because of dependency or tests, we need a polcy
18:41:57 <felixfontein> jillr: I think it makes sense to have a couple of general cases (especially for all collections depending on ansible.netcommon, there are a lot of these), and then the possibility to have exceptions
18:42:26 <samccann> jillr: good point that we definitely need a caveat in the policy that each potential exclusion has unique situations so while Ansible community holds the rights to pin or remove, we cannot provide exact guidelines on when this will apply
18:42:41 <felixfontein> samccann: I think we have to pin because of dependencies. but I think we need to vote on that first, not sure whether everyone agrees :)
18:42:47 <samccann> but yeah, a couple of scenarios would help
18:43:11 <felixfontein> we definitely need a scenario for ansible.netcommon, since all network collections basically need to depend on it
18:43:24 <acozine> I like having a fairly restrictive guideline and. allow exceptions. rather than a fairly permissive guideilne and then h ave to. "come down. hard". on certain. cases
18:43:50 <dmsimard> it doesn't need to be overly specific, having something is better than nothing (see lack of policy regarding removal)
18:43:54 * felixfontein steals some periods from acozine :)
18:44:33 <samccann> maybe something like "if your collection depends on another collection, you are responsible for keeping your collection up to date with updates in the other collection or risk having your collection removed from the package'
18:45:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:16 <dmsimard> samccann: something along those lines could be added as a bullet point to the link I shared above
18:46:49 <andersson007_> samccann: SGTM, i would elaborate a bit more and give a couple of examples
18:46:57 <andersson007_> for maintainers
18:47:11 <acozine> heh,  I'm. on my. laptop. keyboard, and apparently hit the. spacebar. REALLY HARD
18:47:26 <andersson007_> and recommendations
18:49:03 <andersson007_> though people come and go in collections, many of later maintainers will probably not read the collection requirements
18:49:03 <andersson007_> maybe we should move them to docs.ansible.com one day
18:49:07 <andersson007_> they feel stable enough
18:49:20 <andersson007_> seems
18:50:01 <felixfontein> andersson007_: they will likely not read them there either :)
18:50:27 <acozine> nope, but we can point to them when we make "ban warnings" at. least
18:50:29 <samccann> heh
18:50:32 <samccann> who reads docs?!?!
18:50:33 <andersson007_> felixfontein: true, though can be found by chance with higher probability imo:)
18:50:36 <samccann> ;-)
18:51:24 <dmsimard> by better proactively testing for compliance we can warn maintainers about issues
18:51:36 <andersson007_> +1
18:51:43 <felixfontein> I tried to write something down, what do you think? https://github.com/ansible-community/community-topics/issues/94#issuecomment-1117688626
18:53:01 <acozine> looks good, I'd maybe add an example so folks understand what it looks like when a. dependency is violated
18:53:33 <andersson007_> LGTM, i suggest using more (sub-)bullet points
18:53:34 <samccann> #1 sounds like punishment for a collection doing all the right things, but another collection depends on it and isn't doing all the right things. Both get pinned
18:53:54 <andersson007_> +1 to examples
18:54:24 <andersson007_> more bullet points for readability
18:54:47 <andersson007_> at almost 21.00:)
18:54:53 <samccann> or is our plan that the first major Ansible release where this might happen, we pin both, and it must be resolved or the depending collection removed by the next major Ansible release? (aka leaving it all in place for a max of 6 months?
18:55:36 <jillr> the combination of 1 and 2, given for example the kubevirt situation, seems reasonable
18:55:54 <felixfontein> the proposal isn't a subset of 1, 2 and 3, but 1, 2 AND 3
18:56:50 <felixfontein> but I see I forgot to add another point to basicaly forbid dependencies except in certain cases, or for explicitly allowed exceptions (voted on by SC)
18:57:09 <jillr> felixfontein: exactly, with that combination - for that one scenario - that seems like a good balance
18:58:30 <acozine> +1
19:02:50 <felixfontein> ok, I added point 4 (with rules) and examples here: https://github.com/ansible-community/community-topics/issues/94#issuecomment-1117701159
19:03:04 <felixfontein> so basically the proposal is 1-4, including two examples
19:03:05 <briantist> gah sorry I missed most of the meeting
19:03:10 <felixfontein> #chair briantist
19:03:10 <zodbot> Current chairs: acozine andersson007_ briantist cybette dmsimard felixfontein gundalow jillr jtanner mgraves[m] samccann
19:03:26 <briantist> I was in a work meeting, and then I got distracted adding a hurdy-gurdy emoji to our work slack
19:03:34 <briantist> (you know, normal problems)
19:03:37 <felixfontein> #info Please comment on the proposal (rules 1-4, examples 1-2) in https://github.com/ansible-community/community-topics/issues/94#issuecomment-1117688626 and the comment below it.
19:04:13 <felixfontein> if the proposal stabilizes I'll create a vote out of it
19:04:20 <felixfontein> ok, now we already exceeded the time...
19:04:22 <felixfontein> sorry for that :)
19:04:33 <felixfontein> anything else? if not, I'll close the meeting
19:04:35 <felixfontein> #topic open floor
19:04:36 <andersson007_> maybe a PR?
19:04:49 <andersson007_> linked to the comment?
19:05:12 <felixfontein> andersson007_: I'll create one in 1-2 days or so, let's first see whether there is some fundamental critique
19:05:21 <andersson007_> would be easier to suggest changes
19:05:22 <andersson007_> yep
19:05:29 <andersson007_> makes sense
19:05:41 <felixfontein> ok, thanks everyone!
19:05:43 <felixfontein> #endmeeting