18:00:31 <felixfontein> #startmeeting Ansible Community Meeting
18:00:31 <zodbot> Meeting started Wed Mar 23 18:00:31 2022 UTC.
18:00:31 <zodbot> This meeting is logged and archived in a public location.
18:00:31 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:31 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:31 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/645
18:00:31 <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:35 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics
18:00:38 <felixfontein> #topic Updates
18:00:44 <andersson007_> o/
18:00:52 <cybette> o/
18:01:00 <felixfontein> #chair andersson007_ cybette
18:01:00 <zodbot> Current chairs: andersson007_ cybette felixfontein
18:01:19 <briantist> o/
18:01:48 <felixfontein> #chair briantist
18:01:48 <zodbot> Current chairs: andersson007_ briantist cybette felixfontein
18:01:59 <samccann> \o
18:02:00 <felixfontein> #info We have two votes ending today: https://github.com/ansible-community/community-topics/issues/76 https://github.com/ansible-community/community-topics/issues/77
18:02:20 <felixfontein> #chair samccann
18:02:20 <zodbot> Current chairs: andersson007_ briantist cybette felixfontein samccann
18:02:47 <jillr> o/
18:03:07 <felixfontein> #chair jillr
18:03:07 <zodbot> Current chairs: andersson007_ briantist cybette felixfontein jillr samccann
18:03:47 <felixfontein> #info The next Antsibull release will support the new collection links feature (docs/docsite/links.yml file) where collections can provide an Edit on GitHub button, provide links to communication channels, and other links
18:04:16 <andersson007_> 👍
18:04:17 <felixfontein> should be out by end of this week/beginning of next week, and available on devel at most a few days later
18:04:38 <andersson007_> felixfontein: thanks for working on this!
18:04:46 <samccann> woot!
18:04:54 <briantist> nice!
18:04:58 <samccann> do we want to demo this at the next contrib. summit to raise awareness?
18:05:04 <acozine> o/
18:05:20 <cybette> great idea for demo!
18:05:55 <felixfontein> sounds great!
18:07:44 <dmsimard> something has come up, I can't make it, will read backlog later
18:08:06 <briantist> take care dmsimard
18:08:23 <felixfontein> see you later dmsimard!
18:08:26 * acozine waves at dmsimard
18:08:32 <felixfontein> #chair acozine
18:08:32 <zodbot> Current chairs: acozine andersson007_ briantist cybette felixfontein jillr samccann
18:08:39 <felixfontein> sorry almost missed you :)
18:08:56 <felixfontein> is there anything specific you want to discuss today?
18:08:58 <cybette> #action cybette to add Antsibull collection links feature demo to Contrib summit topics
18:09:10 <felixfontein> thanks cybette!
18:09:28 <acozine> heh, I was lurking
18:09:38 <felixfontein> we could talk about the process of removing things from the Ansible package, or the future of the Ansible package, or both combined ;)
18:10:00 <cybette> hot topics 😅
18:10:07 <felixfontein> indeed!
18:10:07 <samccann> heh
18:10:14 <felixfontein> (and a bit sad that dmsimard isn't around for them)
18:10:23 <briantist> I already wrote a novel on the future of the package in the issue 😅
18:10:47 <samccann> there is the one problem area that dmsimard brought up  right before this meeting (bit of a rock vs hardplace situation)
18:10:48 <felixfontein> yeah, that thread has soo many long comments I haven't fully read it yet ;)
18:10:51 <andersson007_> we've got great feedback in the future-of-package topic. now i'm, as the majority, totally OK with keeping things as-is
18:10:52 * acozine looks at her open tabs for that issue
18:10:57 <samccann> if we want to use a specific example to solve
18:11:09 <felixfontein> #topic Removing packages from Ansible package, and the future of the Ansible package
18:11:30 <felixfontein> samccann: do you mean community.kubevirt / community.kubernetes ?
18:11:54 <samccann> yep
18:12:03 <samccann> tho we can talk generic if we have enough peeps
18:13:05 <felixfontein> about these two specific collections, it's probably best to just modify community.kubevirt. since we have access to it that should be no problem.
18:13:32 <andersson007_> what do you mean?
18:13:34 <felixfontein> I think changing the dependency could be done in a minor release
18:13:40 <andersson007_> ah
18:13:48 <felixfontein> right now community.kubevirt depends on community.kubernetes, which is about to go away
18:13:54 <andersson007_> there were couple of attempts already
18:14:02 <samccann> are we comfortable that it will work given it's not a maintained collection?
18:14:05 <felixfontein> (or at least that's what I understood from the discussion above)
18:14:24 <jillr> community.kubernetes is kubernetes.core, it was renamed last year.  same code.
18:14:38 <samccann> oh that helps for sure!
18:14:49 <felixfontein> exactly, and k.core is included in Ansible as well
18:14:54 <jillr> so we could change the references in community.kubevirt (since the community has access, the RH cloud content team does not maintain kubevirt)
18:14:56 <andersson007_> there were issues when a past maintainer tried to solve it
18:15:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:18 <jillr> andersson007_: oh I didn't realize (or forgot)
18:15:20 <felixfontein> andersson007_: were you involved in the collection a bit?
18:15:34 <andersson007_> tadeboro tried
18:15:34 * cyberpear joins late
18:15:39 <andersson007_> then snecklifter
18:15:48 <felixfontein> do you know what the problem was?
18:15:52 <felixfontein> #chair cyberpear
18:15:52 <zodbot> Current chairs: acozine andersson007_ briantist cyberpear cybette felixfontein jillr samccann
18:16:07 <andersson007_> https://github.com/ansible-collections/community.kubevirt/pull/34
18:16:21 <andersson007_> felixfontein: here's the PR ^
18:17:17 <andersson007_> its unit tests failed and the author didn't solve the issue with them
18:17:57 <felixfontein> andersson007_: what's the problem with tadeboro's original PR?
18:18:05 <jillr> oh, but this is moving to k8s.core 2.0 instead of just k8s.core 1.0.0, right?
18:18:23 <andersson007_> felixfontein: i don't remember:)
18:18:28 <felixfontein> hum, except "Do note that we had to introduce an upper bound in the requirements since the kubernetes.core broke backward compatibility with version 2.0.0."
18:18:29 <jillr> currently c.kubevirt depends on community.kubernetes 1.0.0
18:18:32 <felixfontein> that would be a serious problem
18:19:09 <felixfontein> ah, so tadeboro's PR simply changed the dependency to k.c < 2.0.0, and the other PR actually tries to make it work with k.c >= 2.0.0
18:19:18 <felixfontein> which is more complicated if the code changed that much
18:19:39 <samccann> hmmm some of the failures are with 2.9 but 2.9 goes EOL before Ansible 6 releases. Does this mean we can ignore/remove 2.9 tests?
18:19:39 <felixfontein> so basically we cannot just switch the dependency, since the dependency had some breaking changes
18:19:41 <andersson007_> there were some breaking changes introduced in kubernetes.core
18:19:46 <andersson007_> so the code is different
18:19:56 <andersson007_> between community.kubernetes and kubernetes.core
18:20:05 <felixfontein> samccann: only if we make a new major release, but that should be possible
18:20:38 * gundalow waves
18:21:10 <felixfontein> #chair gundalow
18:21:10 <zodbot> Current chairs: acozine andersson007_ briantist cyberpear cybette felixfontein gundalow jillr samccann
18:22:19 <felixfontein> hmm, community.kubernetes is 2.x.y, and we're probably including that in Ansible? which would mean that right now, c.kubevirt as included in Ansible does not actually work?
18:22:20 <jillr> andersson007_: are you saying you found a difference in the code between a same-version of community.k8s and k8s.core?
18:22:55 <felixfontein> jillr: it's not bewteen same-version, but between 1.x.y which community.kubevirt needs, and 2.x.y that's the current version of community.kubernetes and kubernetes.core
18:22:59 <jillr> felixfontein: we would very much like k8s.core 2.x.y to be in ansible, but yes it has changes vs 1.x.y
18:23:13 <jillr> ah, well yeah major version differences  :)
18:23:38 <jillr> is there any maintainer for the kubevirt collection?
18:23:48 <jillr> we could try to offer advice?
18:23:48 <felixfontein> jillr: kubernetes.core 2.x.y is already in Ansible 5
18:23:52 <andersson007_> jillr: i was meant to say what felixfontein said:)
18:24:01 <gundalow> Thanks felixfontein
18:24:03 <felixfontein> so basically kubevirt has been dead for some time now in Ansible...
18:24:07 <felixfontein> apparently :)
18:24:53 <gundalow> > hmmm some of the failures are with 2.9 but 2.9 goes EOL before Ansible 6 releases. Does this mean we can ignore/remove 2.9 tests?
18:24:53 <gundalow> I guess so, though not sure if that might trigger a major collection version bump
18:25:12 <felixfontein> gundalow: it does, but that should be fine
18:25:47 <samccann> If kubevirt is dead in Ansible 5, that seems a good reason to remove it in 6...:-P
18:25:47 <felixfontein> I guess the main question is who wants to invest time in doing the legwork :)
18:26:21 <jillr> so for "all things kube", we have k8s.core 2.x in ansible 5 but also c.k8s 1.x - which is there to support c.kubevirt (which has no maintainer and does not work with k8s.core 2.x).  the question is, if we remove c.k8s 1.x.y as previously planned what do we do with c.kubevirt since it will be broken in ansible 6?
18:26:31 <felixfontein> but we could also make this a slightly different question: if nobody fixes c.kubevirt, after how long should we remove it from the Ansible package?
18:26:57 <felixfontein> jillr: Ansible 5 has community.kubernetes 2.x.y
18:27:15 <jillr> egads, ok thanks
18:27:31 <jillr> so community.kubevirt is broken in ansible-5 unless the user installs a 1.x.y?
18:27:41 <felixfontein> it seems so
18:28:04 <jillr> and is unmaintained, and no one has complained  :)  my vote is to remove it then
18:28:07 <felixfontein> so either c.kubevirt is fixed, or we have to remove it from Ansible
18:28:16 <andersson007_> complained:)
18:28:16 <samccann> someone opened an issue in c.kubevirt related to this
18:28:25 <andersson007_> gimme 10 secs
18:28:30 <felixfontein> there are at least two issues
18:28:33 <samccann> so.. one complaint, and one response to that complaint on how to work around it
18:28:34 <andersson007_> samccann: yep
18:29:16 <acozine> does the workaround work?
18:29:31 <felixfontein> it should
18:29:37 <samccann> so could be a case for a bullhorn announcement - hey we realized this collection stopped working in Ansible5. Since it has no maintainers and is now broken, we plan on removing from Ansible 6 unless someone steps up to fix and maintain it going forward'
18:29:47 <felixfontein> but we cannot revert to c.kubernetes < 2 in Ansible without breaking other users
18:30:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:14 <felixfontein> samccann: yes. ideally that announcement should have already been made some months ago :)
18:30:54 <samccann> yeah just figure given it's been busted, we can mea culpa we didn't notice but now we need to remove w/o a deprecation notice
18:31:22 <felixfontein> IMO if we remove it from Ansible 6, we should have a fast way back in if someone fixes the problems
18:31:34 <felixfontein> actually do we know whether *everything* in that collection is broken, or whether parts still work?
18:31:45 <samccann> we accept 'new' collections at any point now, right? So that's a fast way to get back?
18:32:14 <gundalow> Could folks be using ansible5 and have manually installed a different collection version to get things working
18:32:18 <felixfontein> samccann: yes; we could also skip parts of the regular procedure since it was already part of Ansible before
18:32:35 <felixfontein> gundalow: yes they can. but then it's better if they also install c.kubevirt manually
18:32:37 <jillr> for the sake of transparency, I dont think we'd commit to ensuring that we wouldn't break community.kubevirt again with changes in k8s.core.  If that would be a consideration.
18:32:52 <gundalow> samccann: Correct, so 3 weeks, or I guess we could do a release sooner with only that fix
18:33:19 <jillr> if a maintainer is found that wants to build a relationship with us that's awesome, but it wouldn't be a tested part of our dependencies
18:33:32 <mgraves[m]> jillr: I was going to say the same thing. unless someone steps up to actively maintain the collection, we will be back here again when we release k8s 3.0
18:33:56 <andersson007_> can't we just copy related code from c.k8s to c.kubevirt?
18:33:59 <felixfontein> that's why I hate inter-collection dependencies ;-)
18:34:10 <felixfontein> (that are not tightly coupled, like amazon.aws and community.aws ;) )
18:34:37 <felixfontein> andersson007_: that would be possible, though not really something sustainable either :)
18:34:39 <jillr> k8s.core and community.okd are also that tightly coupled, but community.kubevirt is not a part of that dependency chain / test matrix
18:34:53 <andersson007_> felixfontein: agreed
18:35:06 <jillr> so, use the mod utils and such if you want in other collections but we make no warranties :)
18:35:22 <gundalow> #chair mgraves
18:35:23 <zodbot> Current chairs: acozine andersson007_ briantist cyberpear cybette felixfontein gundalow jillr mgraves samccann
18:35:33 <felixfontein> #chair mgraves[m]
18:35:33 <zodbot> Current chairs: acozine andersson007_ briantist cyberpear cybette felixfontein gundalow jillr mgraves mgraves[m] samccann
18:35:45 <mgraves[m]> copying the code would likely lead to other problems since you will depending on ancient versions of the kubernetes and openshift python clients
18:35:48 <felixfontein> the problem with matrix and irc ;)
18:37:15 <felixfontein> how about the following generic rule: if a collection stops working because it depends on another collection included in Ansible, and is not fixed, it will be removed rom the next major release if not fixed in time. if someone steps up during the next major release cycle of Ansible after the removal and fixes the problems, and promises to maintain it for some more time, it can be re-added
18:37:20 <felixfontein> to Ansible without the usual inclusion process
18:37:44 <jillr> that seems reasonable, we can always revisit if it's a problem
18:37:47 <felixfontein> (we'd of course have to vote for this, and probably it needs some more details on when this should be announced, etc.)
18:37:48 <andersson007_> sounds good to me
18:37:55 <cybette> +1
18:38:22 <mgraves[m]> +1
18:38:24 <felixfontein> if you like it I'll make this a proposal in community-topics, then we can vote on it
18:38:34 <felixfontein> the first step to a removal process :)
18:39:22 <andersson007_> i would suggest starting with a PR against the overview repo
18:39:42 <andersson007_> with a new doc dedicated to removal
18:39:44 <felixfontein> do you mean so we can first fix the wording, and then vote?
18:39:56 <andersson007_> yep
18:40:42 <andersson007_> after polishing we could vote
18:40:44 <felixfontein> what should we do about collections such as community.google, which seem unmaintained, but might still actually work?
18:41:15 <felixfontein> there are no issues, unit tests still seemed to have worked when they got disabled 4 months ago, the only problem were some failing sanity tests
18:41:27 <jillr> is google.cloud included?  /me checks build repo
18:41:39 <felixfontein> (logs are no longer available, so no idea what was wrong... I guess some new tests were added to ansible-test sanity, and nobody added ignore.txt entries or cleaned them up...)
18:41:43 <felixfontein> google.cloud is included
18:42:02 <felixfontein> community.google has some content that isn't autogenerated and probably was community contributed/maintained
18:42:18 <felixfontein> (there's no dependency on google.cloud)
18:42:29 <jillr> I'm fairly confident they're the same code (or at least were historically), I'd favor removing the unmaintained, duplcited community collection if that is true
18:42:35 <jillr> hrm
18:43:05 <felixfontein> I'm also in favor of that, but I think we need a longer deprecation period here since we have no indication that it does no longer work
18:43:14 <felixfontein> (though we have no indication that it works, either...)
18:43:40 <acozine> heh, Schroedinger's collection
18:43:51 <jillr> I'm good with long deprecation but remove it unless a maintainer shows up and demonstates it offers somethign distinct from the GCP collection
18:44:03 <felixfontein> how about announcing the deprecation with planned removal from Ansible 7 now and in the 6.0.0 changelog, with a message that if someone wants to step up as a maintainer and clean it up it can stay in Ansible?
18:44:15 <acozine> +1 for removing duplicate code in an unmaintained collection
18:44:30 <acozine> felixfontein: that sounds like a good approach
18:44:49 <acozine> is that too slow for anybody?
18:45:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:32 <felixfontein> we do ask collections to not do breaking changes too quickly, so IMO we shouldn't do that ourselves if there's no pressing reason (like collection doesn't actually work)
18:45:39 <andersson007_> SGTM
18:45:50 <cybette> +1
18:46:05 <samccann> +1
18:46:15 <andersson007_> folks i have to go now, see you all later
18:46:23 <felixfontein> ok, I guess I'll write a proposal with these two rules then, then we can wordsmith, potentially have some more discussion, and finally vote on it
18:46:27 <felixfontein> bye andersson007_!
18:46:32 <felixfontein> cool
18:46:32 <acozine> bye andersson007_
18:46:35 <cybette> thanks andersson007_ , see you!
18:46:47 <andersson007_> thanks everyone!
18:47:02 <felixfontein> I would avoid to add more to that PR for now, at least without some longer discussion. trying to vote on too many things in one vote is usually not a good idea :)
18:47:03 <jillr> oh wow I would be interested to know if this google collection even still works with the GCP APIs - it's built in part on Amazon's boto2 sdk
18:47:43 <felixfontein> jillr: it would be really interesting. nobody wrote an issue that it doesn't work, but that could also mean that nobody uses it...
18:47:54 <jillr> I suspect no one uses it.
18:48:06 <felixfontein> maybe someone is happily using it (or parts of it) and these parts just work for them...
18:48:20 <felixfontein> I also think so...
18:48:42 <felixfontein> on the other hand, it has 29433 downloads, and I don't think it's included in any other collection's CI (that we know of)
18:49:17 <felixfontein> so at least some people apparently installed it
18:49:18 <jillr> the libcloud versin it uses is ancient
18:49:58 <jillr> yeah, announce a deprecation and remove it
18:50:15 <felixfontein> I guess that probably nobody will speak up on the announcement, and then we probably forget about it and accidentally leave it in Ansible 7 ;)
18:50:26 <jillr> lol, very possible
18:51:02 <gundalow> I'm not sure if we have a breakdown of downloads is last day, week, month, year, all time
18:51:27 <felixfontein> that would be interesting
18:52:00 <gundalow> Guess we have the number from today in the chat logs, so we can see
18:52:18 <felixfontein> true
18:52:21 <felixfontein> if someone remembers :)
18:52:44 <gundalow> I'll set a reminder
18:53:28 <acozine> it's also possible that folks download whatever they find first, and if/when that doesn't work, they search again and download the working collecton for GCP
18:54:15 <briantist> wouldn't every build of the ansible package (even in tests CI for that) also download it?
18:56:02 <felixfontein> briantist: it does, and probably some amount of the downloads comes from that
18:56:12 <felixfontein> but that should be a lot less than 30'000
18:56:17 <gundalow> I wish we have usage data
18:56:39 <briantist> 30,000 is over what time period?
18:56:41 <felixfontein> I wish we had too, but I'm glad we do not have beacuse that's not really privacy compatible :)
18:56:47 <felixfontein> briantist: I guess forever
18:57:34 <cybette> initial commit of that repo is 16 months ago
18:58:57 <felixfontein> can someone re-count the votes in https://github.com/ansible-community/community-topics/issues/76 and https://github.com/ansible-community/community-topics/issues/77 ?
18:59:35 * jillr counts 76
18:59:39 <felixfontein> and if someone wants to further wordsmith, there's https://github.com/ansible-collections/overview/pull/199
18:59:48 <felixfontein> thanks jillr!
19:00:59 <felixfontein> (the PR for #76 is https://github.com/ansible-community/antsibull/pull/342 if anyone is interested)
19:02:37 <felixfontein> anyway, looks like time is up!
19:02:38 <acozine> count on #77 is correct
19:02:40 <felixfontein> Thanks everyone :)
19:02:44 <felixfontein> acozine: can you write that in the issue?
19:02:54 <acozine> will do felixfontein
19:03:06 <jillr> felixfontein: I found one more vote on 76, otherwise lgtm
19:03:30 <felixfontein> acozine: jillr: thanks a lot!
19:03:33 <jillr> np!
19:03:36 <felixfontein> jillr: darn, counting is hard ... :)
19:03:52 <felixfontein> #info https://github.com/ansible-community/community-topics/issues/76 and https://github.com/ansible-community/community-topics/issues/77 have been approved
19:03:53 <jillr> this is why we peer review!
19:03:55 <felixfontein> #endmeeting