18:00:13 #startmeeting Ansible Community Meeting 18:00:13 Meeting started Wed May 4 18:00:13 2022 UTC. 18:00:13 This meeting is logged and archived in a public location. 18:00:13 The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 18:00:13 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:13 The meeting name has been set to 'ansible_community_meeting' 18:00:13 #topic Agenda https://github.com/ansible/community/issues/645 18:00:13 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 #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics 18:00:19 o/ 18:00:20 #topic Updates 18:00:22 hellooooooo o/ 18:00:28 #chair dmsimard 18:00:28 Current chairs: dmsimard felixfontein 18:00:36 o/ 18:00:42 * bcoca does quick wave and goes back to meeting 18:00:48 #info ansible 5.7.1 has been released: https://groups.google.com/g/ansible-announce/c/GmOhXTtmj_w 18:00:50 #chair andersson007_ 18:00:50 Current chairs: andersson007_ dmsimard felixfontein 18:00:51 o/ 18:00:55 * felixfontein waves at bcoca! 18:00:58 #chair resmo 18:00:58 Current chairs: andersson007_ dmsimard felixfontein resmo 18:01:01 #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 o/ 18:01:13 \o 18:01:15 o/ 18:01:16 o/ 18:01:18 andersson007_: will you mention the vmware collection? 18:01:25 #chair mgraves[m] samccann gundalow jillr 18:01:25 Current chairs: andersson007_ dmsimard felixfontein gundalow jillr mgraves[m] resmo samccann 18:01:28 o/ 18:01:40 #chair cybette 18:01:40 Current chairs: andersson007_ cybette dmsimard felixfontein gundalow jillr mgraves[m] resmo samccann 18:01:41 felixfontein: was not going:) 18:01:54 ok 18:02:08 i reviewed resmo's one yesterday 18:02:11 #info Active vote: include vmware.vmware_rest into Ansible (https://github.com/ansible-community/community-topics/issues/99) 18:02:40 ah, stop 18:02:55 there will not be an active vote 18:03:07 we use the new approach there 18:03:11 oh, why? 18:03:17 don't we need to vote on every inclusion request? 18:03:27 by default it'll get merged 11th on May 2022 18:03:41 felixfontein: no:) we voted for that:) 18:03:54 * felixfontein is getting old :D 18:04:00 very meta :) 18:04:00 there was a topic and a pr:) 18:04:11 #info please take the Ansible Contributor Survey (if you haven't already). Thanks! https://www.surveymonkey.co.uk/r/TD328PF 18:04:42 when there are 2 SC reviews and approvals, we create a topic and set up a date 18:05:14 if no concerns are raised, the collection will get included automatically 18:05:22 will be considered, i'd say 18:05:49 so for vmware_rest it'll be on 11th of May 18:06:18 #undu 18:06:20 #undo 18:06:20 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 #undo 18:06:21 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 cybette: sorry, had to undo your's too to undo mine 18:06:43 cybette: can you repost yours? 18:07:11 #info please take the Ansible Contributor Survey (if you haven't already). Thanks! https://www.surveymonkey.co.uk/r/TD328PF 18:07:14 felixfontein: no problem :) 18:07:19 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 :) 18:08:01 #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 ^ 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 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 (the third category is definitely not as bad as the first two :) ) 18:11:41 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 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 in some cases this is likely caused by stable-2.13 not being used in CI right now 18:12:42 but if there are so many, it could mean they are not running at all 18:13:01 i created ~25 issues about adding stable-2.13 18:13:25 at least 1/3 has been fixed 18:13:48 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 (which is why I created https://github.com/ansible-community/community-topics/issues/96 :) ) 18:14:14 i'm going to create a list of collections in ~3 weeks where there were no responces 18:14:51 you still have to decide what to do if the maintainer(s) simply won't or refuse to fix the issues 18:14:51 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 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:15:03 felixfontein: +1 for #96, we should have been doing it proactively sooner 18:15:05 jtanner: indeed, we have to! 18:15:21 60 days 18:15:35 resmo: that is indeed a problem, usually the person who set up the workflow gets informed, but nobody else 18:15:50 GHA is unfortunately pretty spartan w.r.t. notifications 18:16:51 * dmsimard pictures github kicking people into a pit 18:16:57 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 felixfontein, agreed 18:17:27 dmsimard: hmm, I'm more thinking about the meaning "very, very basic" than "kicking ass" :) 18:17:43 Taking a step back. I wonder if we need to change (or add) where tests are done 18:17:43 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 if there's no releases? 18:18:35 isn't AH doing something like that? 18:18:43 (at least for one version) 18:18:46 AH? 18:18:51 RH's automation hub 18:18:57 AH = Automation Hub = GalaxyNG 18:19:10 I've seen the abbreviation 'AH' so often I started using it myself, despite never having used that product ;) 18:19:42 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 o/ 18:19:57 sorry I'm. late, dentist this AM 18:19:58 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 #chair acozine 18:20:02 Current chairs: acozine andersson007_ cybette dmsimard felixfontein gundalow jillr mgraves[m] resmo samccann 18:20:06 #chair jtanner 18:20:06 Current chairs: acozine andersson007_ cybette dmsimard felixfontein gundalow jillr jtanner mgraves[m] resmo samccann 18:20:49 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 what's --failure-ok ? 18:21:22 it means it's non-fatal ? 18:21:46 --failure-ok exit successfully on failed tests after saving results 18:22:09 to run sanity tests somewhere independently from the collections themselves would be great (+ maybe a dashboard) 18:22:18 andersson007_: very doable 18:22:37 👍 18:22:47 https://github.com/ansible/ansible/blob/5c2d830dea986a8c7bd8c286b86bdce326cd7eb1/test/lib/ansible_test/_internal/commands/sanity/__init__.py#L297-L304 18:23:09 jtanner: I didn't ask so much but thanks :D 18:23:17 andersson007_, +1 18:24:53 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 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 felixfontein: call for new maintainers, then put the collection on a "watch list" for removal, maybe? 18:26:06 acozine: we can only call for new maintainers if we have access (i.e. it lives in gh.com/ansible-collections) 18:26:14 watch list --> call it "hot seat" ;) 18:26:21 heh 18:26:23 resmo: +1 :) 18:26:25 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 I guess it should be levelled and depend on the severity of the problem 18:26:51 we have the removal process now, thank you! 18:26:57 you are still allowing 'broken" collections into the distro if they're not immediately purged or fixed 18:27:19 you should have release notes with big red warnings: "These collections are known to be BAD ..." 18:27:22 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 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 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 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 true 18:29:41 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 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 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:30:06 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 bye resmo! thanks for being here! 18:30:24 #unchair resmo 18:30:24 Current chairs: acozine andersson007_ cybette dmsimard felixfontein gundalow jillr jtanner mgraves[m] samccann 18:30:55 bye resmo! 18:31:34 ciao resme 18:31:37 * ciao resmo 18:32:26 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 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 a) aims at collections depending on ansible.netcommon or ansible.utils (all network collections do that) 18:33:06 b) aims at collections such as kubernetes.core and community.okd, or amazon.aws and community.aws 18:34:03 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 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 (not that we really want to do that, but we could, and they have to accept that) 18:34:58 seems okay to me - "if. your collection depends on. another collection you have some special responsibilities" 18:35:24 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 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 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 felixfontein: yeah that's fine, like I said it's worth doing the exercise of "what if" 18:36:54 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 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 the okd collection isn't even in an ansible namespace on github, so this is academic anyway 18:38:21 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 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 jillr: it used to be :) 18:39:09 jillr: the part about the namespace is mostly about last resort of the community working group to "step in" I think 18:39:31 dmsimard: I think we have to pin k8s.core in that case 18:39:43 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 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 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 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 I would assume it would be evaluated in each case. can such a policy be written that covers all possibilities? 18:41:28 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 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 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 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 but yeah, a couple of scenarios would help 18:43:11 we definitely need a scenario for ansible.netcommon, since all network collections basically need to depend on it 18:43:24 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 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 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 @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:45:16 samccann: something along those lines could be added as a bullet point to the link I shared above 18:46:49 samccann: SGTM, i would elaborate a bit more and give a couple of examples 18:46:57 for maintainers 18:47:11 heh, I'm. on my. laptop. keyboard, and apparently hit the. spacebar. REALLY HARD 18:47:26 and recommendations 18:49:03 though people come and go in collections, many of later maintainers will probably not read the collection requirements 18:49:03 maybe we should move them to docs.ansible.com one day 18:49:07 they feel stable enough 18:49:20 seems 18:50:01 andersson007_: they will likely not read them there either :) 18:50:27 nope, but we can point to them when we make "ban warnings" at. least 18:50:29 heh 18:50:32 who reads docs?!?! 18:50:33 felixfontein: true, though can be found by chance with higher probability imo:) 18:50:36 ;-) 18:51:24 by better proactively testing for compliance we can warn maintainers about issues 18:51:36 +1 18:51:43 I tried to write something down, what do you think? https://github.com/ansible-community/community-topics/issues/94#issuecomment-1117688626 18:53:01 looks good, I'd maybe add an example so folks understand what it looks like when a. dependency is violated 18:53:33 LGTM, i suggest using more (sub-)bullet points 18:53:34 #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 +1 to examples 18:54:24 more bullet points for readability 18:54:47 at almost 21.00:) 18:54:53 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 the combination of 1 and 2, given for example the kubevirt situation, seems reasonable 18:55:54 the proposal isn't a subset of 1, 2 and 3, but 1, 2 AND 3 18:56:50 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 felixfontein: exactly, with that combination - for that one scenario - that seems like a good balance 18:58:30 +1 19:02:50 ok, I added point 4 (with rules) and examples here: https://github.com/ansible-community/community-topics/issues/94#issuecomment-1117701159 19:03:04 so basically the proposal is 1-4, including two examples 19:03:05 gah sorry I missed most of the meeting 19:03:10 #chair briantist 19:03:10 Current chairs: acozine andersson007_ briantist cybette dmsimard felixfontein gundalow jillr jtanner mgraves[m] samccann 19:03:26 I was in a work meeting, and then I got distracted adding a hurdy-gurdy emoji to our work slack 19:03:34 (you know, normal problems) 19:03:37 #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 if the proposal stabilizes I'll create a vote out of it 19:04:20 ok, now we already exceeded the time... 19:04:22 sorry for that :) 19:04:33 anything else? if not, I'll close the meeting 19:04:35 #topic open floor 19:04:36 maybe a PR? 19:04:49 linked to the comment? 19:05:12 andersson007_: I'll create one in 1-2 days or so, let's first see whether there is some fundamental critique 19:05:21 would be easier to suggest changes 19:05:22 yep 19:05:29 makes sense 19:05:41 ok, thanks everyone! 19:05:43 #endmeeting