#ansible-community log

18:00:30 <felixfontein> #startmeeting Ansible Community Meeting
18:00:30 <zodbot> Meeting started Wed Apr  6 18:00:30 2022 UTC.
18:00:30 <zodbot> This meeting is logged and archived in a public location.
18:00:30 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:30 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:30 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/645
18:00:30 <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:34 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/645 / Topics: https://github.com/ansible-community/community-topics
18:00:35 <andersson007_> o/
18:00:37 <felixfontein> #topic Updates
18:00:44 <jtanner> hi
18:00:45 <briantist> o/
18:01:00 <felixfontein> #chair andersson007_ dmsimard cybette jtanner briantist
18:01:00 <zodbot> Current chairs: andersson007_ briantist cybette dmsimard felixfontein jtanner
18:01:43 <felixfontein> #info 6 days until the Contributor Summit! \o/
18:01:59 <cyberpear> o/
18:02:01 <andersson007_> #info There's the inclusion request for the ibm.spectrum_virtualize collection that needs the second review by a SC member https://github.com/ansible-collections/ansible-inclusion/discussions/35.
18:02:11 <samccann> \o
18:02:18 <cybette_> o/ (partly)
18:02:22 <felixfontein> #info felixfontein is working on splitting up the antsibull package, see https://github.com/ansible-community/antsibull/issues/410 for details
18:02:30 <felixfontein> #chair cyberpear samccann
18:02:30 <zodbot> Current chairs: andersson007_ briantist cyberpear cybette dmsimard felixfontein jtanner samccann
18:03:02 <felixfontein> #info 6 days until the first Ansible 6.0.0 alpha release!
18:03:19 <jtanner> felixfontein: could just go with tried and true git submodules
18:03:54 <jillr> o/
18:03:56 <acozine> o/
18:04:03 * acozine is grabbing fresh tea
18:04:08 <felixfontein> #chair jillr acozine
18:04:08 <zodbot> Current chairs: acozine andersson007_ briantist cyberpear cybette dmsimard felixfontein jillr jtanner samccann
18:04:46 <felixfontein> if you're interested to look at the Ansible 6 schedule: https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/COLLECTIONS_6.rst#release-schedule
18:05:28 <felixfontein> #info community.general 4.8.0 (April 26th) will likely be the last 4.x.0 minor release, and 5.0.0 will likely be released on May 17th to make it into Ansible 6.0.0 alpha 3
18:06:11 <felixfontein> based on how this worked for previous releases, I just picked these dates, put a 'likely' before, and will let them become reality if nobody complains :)
18:06:19 <andersson007_> felixfontein: thanks for the info!
18:06:29 <dmsimard> I've asked for a 15m timeslot during contrib summit so I can live demo and explain the build of 6.0.0a1 :D
18:06:40 <acozine> heh
18:06:45 <felixfontein> cool!
18:06:56 <acozine> live demo! living on the edge
18:07:08 <dmsimard> what could go wrong
18:07:24 <jillr> github outage incoming!
18:07:43 <acozine> jillr: planned? current?
18:07:51 <dmsimard> thankfully the build can /not/ rely on github.. galaxy, on the other hand..
18:07:57 <jillr> acozine: just an answer to "what could go wrong in a live demo"
18:08:01 <acozine> heh
18:08:02 <jtanner> oh, it is github outtage roulette game day?
18:08:46 <felixfontein> maybe it will be galaxy outage day - that's the service we cannot release ansible without ;-)
18:08:53 <felixfontein> or pypi
18:09:14 <jillr> I don't want to jinx the galaxy team folks like that :)
18:09:34 <jtanner> *shrug*, it's amazingly stable compared to hub
18:09:59 <dmsimard> sorry for sidetracking the meeting, we can move on :p
18:10:20 <felixfontein> cybette_: are you managing the schedule for the summit? I can do that demo on collection docs (links, + general short how-to create a collection docsite with antsibull) that someone added in https://hackmd.io/@ansible-community/contrib-summit-202204/%2FzxOZe_FzR7a9-pw6r6_Ypg for me :)
18:10:40 <felixfontein> jtanner: automation hub, or docker hub?
18:10:46 <felixfontein> (or some other hub?)
18:10:52 <jtanner> automation-hub/galaxy_ng
18:11:03 <jtanner> console.redhat.com/etc
18:11:07 <felixfontein> I can't use that one, so no idea :)
18:11:40 <felixfontein> ok, so what do you folks want to talk about today?
18:11:41 <cybette_> felixfontein: that's great, is 30 min sufficient?
18:11:53 <felixfontein> cybette_: I think that 15-20 minutes should be fine as well
18:12:07 <cybette_> felixfontein: ack, thanks!
18:12:12 <felixfontein> cybette_: I'm a bit afraid it will get boring if it's 30 minutes :)
18:13:27 <felixfontein> I have to admit that I still have to rework https://github.com/ansible-collections/overview/pull/201 (Describe how collections can be removed from the Ansible package [WIP]), there were too many things going on...
18:13:56 <felixfontein> I'm not sure whether we should/want to continue discussing collection removal until we can take another look at that one
18:14:39 <felixfontein> we can talk about the dependency of ansible on ansible-core (https://github.com/ansible-community/community-topics/issues/84)
18:15:07 <felixfontein> there are also a lot of documentation related discussions going on in https://github.com/ansible-community/community-topics/
18:15:10 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:51 <felixfontein> also andersson007_ wants to advertise that https://github.com/ansible-collections/ansible-inclusion/discussions/35 needs a second SC review
18:16:17 <felixfontein> if you have time to review the ibm.spectrum_virtualize collection, please look at that discussion!
18:17:03 <samccann> I can probably move the pip install one to implementing. I need to sit down with dmsimard and just figure out what that 2nd 'other ways to install' page should have before 2.13 releases
18:17:21 <andersson007_> felixfontein: thanks for mentioning!
18:17:27 <felixfontein> samccann: sounds good to me!
18:17:47 <dmsimard> samccann: ++
18:18:33 <dmsimard> I haven't done my homework on #84
18:18:58 <samccann> some I might leave until after contrib. summit and then close out or something. I mean doc strategy - dont want to live it as 'being implemented' for the next 2 yrs
18:19:02 <dmsimard> felixfontein: collection removal is probably the one time-sensitive topic to wrap up if we want to do it before 6.0.0a1
18:19:06 <samccann> s/strategy/priority/g
18:19:58 <felixfontein> dmsimard: I don't think we can really remove something for 6.0.0 (except if it's totally broken), since we had a deprecation period mentioned in all proposals we had so far
18:20:24 <dmsimard> :(
18:20:42 <felixfontein> well, except community.kubernetes, since we announced that a longer time ago: https://github.com/ansible-community/community-topics/issues/22
18:21:13 <dmsimard> I saw a report that servicenow.servicenow was broken recently, same for community.kubevirt
18:21:18 <felixfontein> though we haven't said that we will remove it yet
18:21:49 <dmsimard> community.azure was deprecated in 5, so probably OK to be superseded by azure.azcollection
18:21:50 <felixfontein> there was some discussion about rebooting community.kubevirt, did anyone follow whether that actually led to something?
18:22:53 <dmsimard> I haven't heard anything about community.google being broken but it should also be superseded by google.cloud -- the other candidates for removal were due to neglect and I'm less in a hurry to tackle those
18:22:54 <andersson007_> didn't notice any activity there
18:23:00 <andersson007_> in c.kubevirt
18:23:04 <felixfontein> I don't think there was a collection deprecation in the 5 changleog (it should be in here: https://github.com/ansible-community/ansible-build-data/blob/main/5/changelog.yaml)
18:23:14 <dmsimard> felixfontein: it's in the collection itself
18:23:33 <felixfontein> I would argue that collection removals must be announced in the Ansible changelog
18:23:33 <dmsimard> https://github.com/ansible-collections/community.azure/commit/bd6fb1a0952407f8f5950194190243b8eb72f8e2
18:24:00 <andersson007_> the last thing happened in c.kubevirt was https://github.com/ansible-collections/community.kubevirt/issues/27#issuecomment-1077464808
18:24:34 <felixfontein> I also don't see how cloud.google superseeds community.google, these are unrelated collections AFAIK
18:25:41 <samccann> there was at least one complaint about `servicenow.servicenow` and that it should be replaced with.. erm  `servicenow.itm` or some such replacement.
18:25:57 <samccann> But I think it's caught up in nobody doing the deprecation properly on the older one?
18:26:39 <felixfontein> since the new version never applied for inclusion, we don't have the replacement in Ansible
18:26:42 <dmsimard> samccann: servicenow.itsm isn't in the ansible package but yes
18:27:25 <felixfontein> samccann: where did you see the coplaint that servicenow.servicenow is broken?
18:27:29 <samccann> dmsimard: yeah seems it's lingered since Ansible 5 so would be good to either deprecate or remove
18:27:39 <samccann> Someone pinged me internally asking me to fix the docs ;-)
18:28:01 <samccann> I explained the docs reflect the package etc etc. Let me see if anything pointed to an external comment somewhere
18:28:11 <dmsimard> felixfontein: re: changelog, that's fair, we can add one in 5.7.0 and/or 6.0.0
18:28:33 <felixfontein> if we want to remove it, we a) need to finalize a procedure for that, and b) we probably need indication that everything in the collection no longer works
18:29:08 <samccann> ok looks like it was a customer talking to an internal RH person. But they did confirm it's broken:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/8b3e9b96544a3bbd56a7cdfb8c7eacd4626f6962)
18:29:39 <samccann> sorry thought I was only copying the bit about it being broken
18:29:48 * samccann goes back to copy pasta kindergarten
18:29:54 <jillr> I need to drop early for another meeting, apologies - I'll catch up on the scrollback later
18:30:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:26 <felixfontein> samccann: it sounds like it is a bit challenging to install the dependencies, but still possible to do that, so it's not really broken IMO
18:30:39 <samccann> heh ok
18:30:45 <felixfontein> it's not really in a great state either though :) but at least it does not warrant immediate removal
18:30:53 <felixfontein> it should have a proper deprecation period
18:31:19 <samccann> makes sense. do we have the ability to force the deprecatoin into the collection? dmsimard I think opened an issue for it months ago but nothing happened
18:31:44 <samccann> https://github.com/ServiceNowITOM/servicenow-ansible/issues/71
18:32:02 <felixfontein> we don't, but we can announce the deprecation in the Ansible changelog
18:32:02 <acozine> our deprecation would just be "the whole collection is deprecated", right?
18:32:11 <dmsimard> I suppose we need to figure out deprecation in the collection vs deprecation in the package ? like say, community.azure has been deprecated from within the collection since 5.0.0 but we haven't mentioned it in the porting guide/changelog
18:32:29 <dmsimard> actually we might, let me go check
18:32:30 <felixfontein> but for now we haven't managed to come up with deprecation procedures. we really need to get *that* done first before we can start deprecating or even removing stuff
18:32:55 <dmsimard> oh, community.azure deprecation has indeed been logged https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_5.html#community-azure
18:33:30 <felixfontein> dmsimard: but that's the *collections* changelog, and it does not say when the collection will be removed from the Ansible package
18:33:36 <felixfontein> things can be deprecated and still be around for yeras
18:34:44 <dmsimard> sure, but let's be careful about making collection removal harder than collection inclusion :p
18:35:08 <andersson007_> +1
18:35:22 <felixfontein> right now we're making collection removal next to impossible by never finalizing any procedure for that.
18:35:24 <samccann> so we require both? An ansible package deprecation (in the porting guide) and a collection-level deprecation (in the changelog and presumably during playbook runtime it pops up as a warning?)
18:36:14 <felixfontein> samccann: I would say no, the collection itself cannot make any statements about Ansible itself, so the collection changelog cannot say when something is added to/removed from Ansible
18:36:58 <felixfontein> if a collection is deprecated (which is something that's unrelated to Ansible) it should release a version which prints deprecation warnings
18:37:05 <felixfontein> deprecating a collection in Ansible is a completely separate thing
18:37:18 <felixfontein> and there's no way to add runtime warnings for that specifically
18:37:43 <felixfontein> (only if the collection itself is deprecated at the same time, *and* the collection is controlled by us)
18:37:58 <samccann> felixfontein: but when a collection is being replaced, that shows up somewhere right? Like communty.foo is going to foo.bar?
18:38:04 <acozine> felixfontein: agreed - what would be the most helpful thing any of us could do today to make collection removal possible? Reviews on ansible-collections PR 201?
18:38:05 <samccann> Okay but in order to depracate a collection in Ansible, do we REQUIRE the collection is deprecated (with those warnings)? or not
18:38:21 <samccann> ok gotcha thanks.
18:39:33 <felixfontein> acozine: getting 201 finished and merged would be a first step, then we have at least some procedures. then we can start using them and add more.
18:40:07 <felixfontein> samccann: we cannot and should not require that IMO
18:40:53 <felixfontein> just because we remove it from Ansible doesn't mean the collection itself is deprecated (community.google could be such a case, if we really want to remove it)
18:40:54 <acozine> Thanks.
18:41:02 <acozine> I'll put a review on it by Friday
18:41:33 <felixfontein> acozine: that would be awesome! I'll try to do the rewrite andersson007_ suggested today
18:41:49 <dmsimard> acozine: appreciate the help!
18:41:52 <samccann> makes sense, yeah
18:43:09 <felixfontein> we could make an ad-hoc decision (vote) on removing community.kubevirt from Ansible 6 since it's broken, and has been broken since Ansible 5.0.0
18:43:31 <felixfontein> but someone would have to propose that and start a vote on it, and we should finish that before 6.0.0a1 is released, i.e. in < 6 days
18:43:56 <acozine> +1 to removing it
18:44:27 <acozine> I'm happy to propose and start a vote, but I won't be much help in executing the removal
18:44:55 <jtanner> remind me how it got broken?
18:44:59 <felixfontein> once it is fixed we can re-add it to Ansible 6.x.0 (as probably described in the procedure we'll finalize only after removing it)
18:45:07 <acozine> PROPOSAL: Since the community.kubevirt collection is broken and has been for a long time, we remove it from the Ansible package as soon as possible.
18:45:16 <felixfontein> jtanner: it needs community.kubernetes < 2, but Ansible 5 includes community.kubernetes 2.x.y
18:45:20 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:33 <felixfontein> acozine: you have to create a discussion / vote issue for that :)
18:45:36 <jtanner> how does that situation not happen again?
18:45:49 <acozine> failure to maintain
18:45:59 <felixfontein> jtanner: it can always happen if there are dependencies between collections
18:46:15 <jtanner> nothing tries to build a dep map during distribution creation?
18:46:15 <felixfontein> but if there are active maintainers it shouldn't really happen, or at least only be broken for a short amount of time
18:46:22 <acozine> it probably will, that's why we're putting together procedures to follow when it happens in future
18:46:55 <felixfontein> jtanner: right now no. but even if we would, we'd still need some procedure what to do when that happens
18:47:02 <felixfontein> that = some mismatch
18:47:17 <jtanner> imo, that procedure is that CI fails and distro doesn't ship until CI passes
18:47:32 <dmsimard> jtanner: there should be something like dep closure, it does not yet exist -- and yes, we should gate on it passing (if it existed)
18:47:45 <felixfontein> jtanner: if we would be paid fo this this would be OK, but we're not.
18:47:55 <dmsimard> there was a WIP here but we didn't follow up on it: https://github.com/ansible-community/antsibull/pull/270
18:48:04 <felixfontein> jtanner: the solution should be more like 'if this isn't fixed in a certain amount of time, the collection is kicked out of the distro'
18:48:05 <jtanner> understood. not saying you all have to give up your unpaid volunteer time to fix all the things
18:48:54 <felixfontein> also we can only fix it if we have actually access to the collection in question (in this case we have, but in general we do not)
18:49:47 <felixfontein> except if fixing means kicking the collection out, that's something we can do, and that's what we will likely do once we have that procedure in place :)
18:50:46 <felixfontein> dmsimard: it's probably helpful if `antsibull-build rebuild-single` prints out a warning if there's some mismatch
18:51:05 <dmsimard> indeed
18:51:22 <dmsimard> I will try and find out if I can carry on Toshio's flame on that
18:52:16 <felixfontein> it shouldn't be hard to implement that, Toshio did the hard work already
18:52:43 <dmsimard> It seems so, yes
18:52:48 <felixfontein> though I would wait a bit until the antsibull split-up is more or less completed, or at least finalized enough :)
18:53:46 <felixfontein> #topic open floor
18:53:59 <felixfontein> I think we basically had 'open floor' the whole time already, so let's make it official ;)
18:54:51 <dmsimard> eh, fwiw running it as-is yields one conflict: community.okd version_conflict: kubernetes.core-2.3.0 but needs >=2.1.0,<2.3.0
18:55:12 <dmsimard> /me looks
18:55:37 <acozine> heh
18:55:47 <acozine> we're an unruly group at times
18:56:11 <felixfontein> seriously, if community.okd has such a narrow dependency they are doing something wrong :)
18:56:56 <dmsimard> just looked and yeah: https://github.com/openshift/community.okd/blob/80e2692db21649b3a57bcd00ecd121fc3daa0c09/galaxy.yml#L8
18:57:17 <dmsimard> and 2.3.0 was released 21 days ago
18:57:39 <dmsimard> so either it's really broken (probably not) or they just need to lift the requirement a bit
18:58:08 <dmsimard> need to go back to afk, be back later
18:58:22 <felixfontein> they already 'relaxed' the requirements 6 months ago: https://github.com/openshift/community.okd/pull/109
18:58:27 <felixfontein> before it was `>=2.1.0,<2.2.0`
18:58:53 <felixfontein> so either they are using internal APIs from kubernetes.core, or kubernetes.core doesn't stick to semver, or they are wrongly paranoid
18:59:55 <felixfontein> I hope it's c), and not a) or b)
19:00:10 <felixfontein> dmsimard: would be great if you could check :)
19:00:15 <felixfontein> anyway, thanks everyone!
19:00:36 <felixfontein> and feel free to talk more in this meeting. I feel like I was writing way too many lines here :)
19:00:39 <felixfontein> #endmeeting