18:00:30 <felixfontein> #startmeeting Ansible Community Meeting
18:00:30 <zodbot> Meeting started Wed Apr 27 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:37 <felixfontein> #topic Updates
18:00:41 <andersson007_> o/
18:01:00 <felixfontein> #chair andersson007_
18:01:00 <zodbot> Current chairs: andersson007_ felixfontein
18:01:02 <samccann> \o
18:01:04 <acozine> o/
18:01:14 <felixfontein> #chair samccann acozine
18:01:14 <zodbot> Current chairs: acozine andersson007_ felixfontein samccann
18:01:30 <gundalow> o/
18:01:57 <felixfontein> #chair gundalow
18:01:57 <zodbot> Current chairs: acozine andersson007_ felixfontein gundalow samccann
18:03:56 <dmsimard> o/
18:04:05 <felixfontein> #chair dmsimard
18:04:05 <zodbot> Current chairs: acozine andersson007_ dmsimard felixfontein gundalow samccann
18:05:23 <felixfontein> Today one vote is ending: https://github.com/ansible-community/community-topics/issues/90 if you stlil want to vote, please do so quickly!
18:06:04 <andersson007_> #info We are happy to announce that Alexei Znamensky [russoz](https://github.com/russoz) has recently joined the [Ansible Community Steering Committee](https://docs.ansible.com/ansible/devel/community/steering/community_steering_committee.html). Welcome, Alexei! Thank you for joining us and your great long-term contribution!
18:06:33 <acozine> welcome russoz !
18:06:46 <samccann> Welcome russoz !!
18:06:54 <felixfontein> welcome russoz[m] indeed :)
18:07:13 <andersson007_> there's ~6 am in russoz[m]: 's area now:) So he'll read our congratulations later
18:07:28 <acozine> oh, goodness
18:07:28 <gundalow> Brilliant stuff
18:07:31 <andersson007_> great path!
18:08:01 <gundalow> I think it's great that we are getting folks from different TZ, helps the asynchronous topics honest
18:08:09 <andersson007_> yep
18:08:17 <felixfontein> definitely!
18:08:54 <felixfontein> #info Ansible 4.7.0 has been released
18:09:24 <dmsimard> 5.7.0*
18:09:27 <dmsimard> #undo
18:09:27 <zodbot> Removing item from minutes: INFO by felixfontein at 18:08:54 : Ansible 4.7.0 has been released
18:09:30 <briantist> sorry will miss today's meeting, forgot to mention (am just here for a moment)
18:09:36 <dmsimard> #info Ansible 5.7.0 has been released
18:09:48 <acozine> we'll mess you briantist
18:09:53 <felixfontein> oops! thanks, dmsimard :)
18:10:01 <felixfontein> the 4 comes from community.general ;)
18:10:13 <samccann> heh sounds like a threat acozine ;-)
18:10:19 <felixfontein> acozine: I hope you mean 'miss' ;)
18:10:26 <acozine> heh
18:10:33 <acozine> yes, I did mean 'miss'
18:10:44 <acozine> five days away from the computer and I can't type
18:11:20 <felixfontein> #info Please don't forget to vote on https://github.com/ansible-community/community-topics/issues/92 (community.kubevirt removal from Ansible 7) and https://github.com/ansible-community/community-topics/issues/93 (community.kubernetes removal from Ansible 7)
18:11:47 <andersson007_> familiar feeling
18:11:54 <andersson007_> after PTO usually
18:11:56 <felixfontein> I added a vote count to https://github.com/ansible-community/community-topics/issues/90, would be great if someone can confirm the numbers
18:12:05 <andersson007_> looking
18:12:12 * felixfontein hasn't had a PTO without computer for a loooong time
18:13:38 <andersson007_> felixfontein: done
18:13:39 <felixfontein> #info Please also take a look at the following two discussions related to collection removal and Ansible package maintenance: https://github.com/ansible-community/community-topics/issues/94 https://github.com/ansible-community/community-topics/issues/96
18:14:00 <andersson007_> felixfontein: 5 days for example is a long time?:)
18:14:12 <gundalow> Could I please get #chair so I can do some updates?
18:14:12 <andersson007_> i guess yes:)
18:14:27 <acozine> #chair gundalow
18:14:27 <zodbot> Current chairs: acozine andersson007_ dmsimard felixfontein gundalow samccann
18:15:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:21 <felixfontein> gundalow: I #chair'ed you 14 minutes ago :)
18:15:30 <dmsimard> There is an item about jillr stepping down from the steering committee, not sure whether we want to put it in an update but I did want to extend my heartful thanks to jillr for being around
18:15:53 <andersson007_> +1
18:16:03 <gundalow> felixfontein: oh, before I was here, very efficient :)
18:16:03 <andersson007_> the last day will be 30 April
18:16:09 <gundalow> #info Pinakes is the upstream community project for Red Hat's Automation Services Catalog product. You can join the discussion in #pinakes:ansible.im  (`#ansible-pinakes` on Libera.chat)
18:16:18 <jillr> hey! sorry I can't be here live this week, I'm in another meeting (thus the recognition of the demands on my time, and stepping down)
18:16:30 <felixfontein> gundalow: right after you wrote "o/" :)
18:17:04 <felixfontein> jillr: thanks for all your work in the committee! and I'm really glad you're still around in general :)
18:17:15 <andersson007_> +100
18:19:42 <felixfontein> btw, today bcoca's sidecar yaml docs PR got merged, so in devel branch it's now possible to document filter and test plugins! I'm currently looking at supporting that in antsibull-docs as well
18:19:53 <briantist> thanks jillr !! 👏
18:19:53 <acozine> wow
18:20:27 <acozine> jillr: we will miss you, not just today, but long into the future
18:20:41 <jillr> <3  I'll be around!
18:20:56 <acozine> re: the sidecar PR . . . I did not think I would live to see the day
18:21:11 <samccann> yay for side car docs!
18:21:24 <samccann> and support coming in antsibull-docs so we can see 'em on the docsite!
18:22:59 <andersson007_> 👍
18:28:09 <felixfontein> I would be interested to hear what folks think about the discussion topics of https://github.com/ansible-community/community-topics/issues/94 and https://github.com/ansible-community/community-topics/issues/96
18:28:35 <felixfontein> the first topic is "What to do on Ansible collection dependency violations?", the second "Generic sanity check for all collections"
18:29:02 <samccann> in general I like the idea of a generic sanity test for all collections. Not sure how deep it could go
18:29:16 <felixfontein> both are about problems the current Ansible package has: 1) community.okd is not compatible with kubernetes.core, and 2) fortinet.fortios is partially totally broken (some modules have syntax errors)
18:30:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:04 <felixfontein> the first makes it impossible to create an Execution Environment for Ansible, and the second makes it impossible to package Ansible for Debian (and thus also Ubuntu) without the user getting errors when installing the package
18:30:07 <samccann> the dependency one feels more difficult. I see what you are saying about not being able to build an EE from it, but how important is that vs having 'batteries included'?
18:30:20 <acozine> +1 for adding a nightly (or weekly) check
18:30:50 <felixfontein> samccann: not being able to build an EE shows that we include an invalid version combination; whether the collections are actually incompatible is another question
18:30:54 <samccann> or is this more like a user of kubernetes.core might be the same user for community.okd (aka somewhat related collections) and they can't use both with the current problems?
18:30:58 <acozine> it would be nice to have a way to say "this collection has a problem, you can see the problem here"
18:31:12 <acozine> instead of learning that a collection is broken from user complaints
18:31:19 <felixfontein> samccann: if someone just uses kubernetes.core they are ine. but community.okd depends on kubernetes.core, so users of it might be impacted
18:32:25 <felixfontein> we don't have time to fully investigate (i.e. review) every collection, but having some sanity checks (like running `ansible-test sanity --docker -v`) is definitely a good thing IMO
18:32:33 <gundalow> Agree we need some sort of nightly test driven by `ansible.in`, I think dmsimard has thought about this in the past
18:32:46 <felixfontein> also making sure that the collection's dependencies don't contradict is important IMO
18:33:24 <felixfontein> gundalow: yes, I remember that, but I didn't find anything in a (very) quick search
18:33:26 <dmsimard> gundalow: yes, ideally we should also be able to run that suite of tests on the results of an ansible package build
18:33:44 <samccann> these two feel like related collections. What happens when say collection.foo has a dependency of version 1.2 of 'bar'... but collection.squiggle (totally unrelated) depends on version 2.0 of 'bar'?
18:34:10 <felixfontein> samccann: that would be a similar problem, and something we should strive to avoid
18:34:22 <samccann> so foo is for say security folks,  squiggle is for daisy-farmers... They may never overlap
18:34:30 <felixfontein> samccann: if there is an earlier set of versions for these three collections that fits together, we can stick to that one until the problem is fixed
18:35:07 <felixfontein> if all of them want to be in ansible, they still have to fit together. otherwise we'll have to kick (at least) one out - IMO
18:35:17 <samccann> ok but we'd need a 'fallback' plan. If the offending collection doesn't react to update their dependencies, we don't want to leave the more frequently maintained collection stuck at some ancient version
18:35:28 <andersson007_> you know, the situation with dependencies feels like it's becoming a nightmare. can the dependencies between collections be forbidden?
18:35:34 <andersson007_> brainstorming
18:36:07 <andersson007_> it would probably imply code duplication but anyway
18:36:11 <felixfontein> samccann: that's kind of a problem indeed. basically a unmaintained version can force a maintained collection to be stuck at an old version - except if we forcefully remove the unmaintained one. but that's a breaking change, and we want to conform to semver.
18:36:15 <acozine> how many dependencies between collections do we have?
18:36:16 <samccann> either limit the dependencies, or hold any collection with said dependencies to a 'higher standard' to update their dependencies or get removed at some point
18:36:42 <felixfontein> andersson007_: then we have to remove all network collections (they all depend on ansible.utils and ansible.netcommon) and community.aws
18:36:48 <acozine> my sense is that many of the cloud collections are sub-divided, so they have dependencies
18:36:55 <andersson007_> felixfontein: oh..
18:37:05 <acozine> and yeah, the network ones all depend on netcommong
18:37:07 <acozine> s/netcommong/netcommon/
18:37:13 <felixfontein> netcommon depends on utils I think
18:37:19 <acozine> are there other "sets" of collections?
18:37:31 <andersson007_> a chain of dependencies..
18:37:43 <andersson007_> or dependency hell
18:37:47 <acozine> but overall my sense is that collection dependencies are the exception, is that not true?
18:37:59 <felixfontein> there's kubernetes.core, community.okd and community.kubevirt; the latter has its own problems (because it will depends on community.kubernetes < 2.0.0 but doesn't declare that)
18:38:12 <felixfontein> acozine: most collections try to avoid it, luckily :)
18:38:17 <samccann> the network collections are all afaik owned by the same 'team' so to speak.
18:38:31 <samccann> but okd and kuberneetes.core are not
18:38:32 <felixfontein> we successfully removed all dependencies community.general and community.network had (except the ansible.netcommon dependency of community.network)
18:38:45 <acozine> yeah, I don't think we need to worry about the network ones getting out of sync
18:38:51 <andersson007_> thanks felixfontein for that!
18:39:00 <felixfontein> samccann: except community.network, which is now owned by the community team since nobody else wants it...
18:39:20 <felixfontein> or let me say "owned" :)
18:39:30 <gundalow> Officially ignored by :)
18:39:35 <samccann> heh
18:39:44 <andersson007_> can we duplicate the code and forbid dependencies in not network collections?
18:39:44 <samccann> that's a valid point that breaks the 'one team' paradigm for sure
18:39:46 <gundalow> (for those that don't know, that's my team I'm talking about)
18:41:03 <felixfontein> it's probably a good idea to limit dependencies to very specific cases; like if someone wants to depend on something owned by another team they have to promise to update their dependencies ASAP, or they will get kicked out super-fast
18:41:16 <gundalow> Do we think it's possible to walk over all the collection dependencies listed in all the collections in `ansible` and ensure the name/versions don't conflict/are missing?
18:41:24 <felixfontein> I'm not sure whether we want to violate semver for that though
18:41:40 <felixfontein> gundalow: there's now code for that in antsibull :)
18:41:58 <felixfontein> so far the only problem is community.okd, which depends on an older verison of kubernetes.core
18:42:12 <samccann> a question on that fast kicking out - how does the end user know this could happen?
18:42:13 <felixfontein> (and community.kubevirt which doesn't declare its dependency correctly... but that's probably removed soon)
18:42:39 <samccann> like I use community.okd and have no idea it's violating a dependency rule.
18:42:43 <felixfontein> samccann: assuming they don't read the changelog, porting guide and release announcement, they notice that their playbook(s) stop working
18:42:49 <samccann> and could get the boot mid-cycle
18:42:58 <samccann> ooch
18:43:13 <felixfontein> that's why I really would like to avoid kicking something out in the middle of a cycle
18:43:34 <felixfontein> unfortunately this means that anther collection might be stuck to an older version for up to 6 months
18:43:37 <samccann> a cycle is 6 months long, roughly, right?
18:43:43 <felixfontein> yes
18:44:21 <felixfontein> ah, there's also community.routeros that depends on ansible.netcommon that's not handled by the same team
18:44:31 <felixfontein> (disclaimer: I'm one of its co-maintainers)
18:44:39 <samccann> heh
18:45:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:03 <samccann> ok trying a mental walkthrough here
18:45:13 <samccann> i use okd. It gets the boot
18:45:21 <samccann> I can just download it from galaxy, right?
18:45:35 <samccann> assuming I am not also using kubernetes.core
18:45:45 <felixfontein> yes
18:45:47 <samccann> and if I am, then I have to download the older kubernetes.core, right? and it all works?
18:46:25 <felixfontein> hmm, good question, I'm not sure what `ansible-galaxy collection install` does when you try to install something that needs an older version of a collection that you have currently installed
18:46:35 <samccann> so maybe a mid-cycle boot isn't as bad as I'm thinking, so long as we announce that it could happen in the porting guide/annoucements etc
18:46:37 <felixfontein> maybe force-install works, maybe it does not
18:47:04 <samccann> yeah we probably need docs on how to recover if you use a collection that's been removed from Ansible
18:47:55 <samccann> we'll probbly still get flack for not having deprecation warnings. I think folks really depend/expect them and this is an area where we can't do that
18:48:22 <felixfontein> so we need to a) determine whether we really want to kick something out mid-cycle, and b) how long we wait (by keeping the version it depends on back) before kicking it out if we do
18:48:25 <samccann> I don't suppose there's a clever way to add a deprecation warning feature into ansible the package to pick up on this?
18:48:42 <felixfontein> there isn't
18:48:48 <felixfontein> unfortunately
18:50:19 <andersson007_> ansible.netcommon is a great point of failure, should get untouchable
18:50:22 <samccann> I could foresee a case where we struggle on 'who to blame' so to speak
18:50:29 <samccann> yeah thinking of that one
18:50:40 <jtanner> blame me, that's usually accepted
18:50:44 <felixfontein> :)
18:50:51 <andersson007_> :D
18:50:57 <samccann> if netcommon makes drastic changes, who's responsible for the dependent collections? I mean if it's specifically designed to be COMMON
18:51:06 <felixfontein> I'd always blame the collection which didn't manage to update their dependencies :)
18:51:28 <felixfontein> samccann: drastic changes usually mean a new major version, which only gets included for the next release cycle
18:51:36 <samccann> yeah but say 20 outside collections (not part of that team) start depending on these common tools.
18:51:50 <felixfontein> samccann: and if we drop something out for a new major version, it's not a violation of semver ;)
18:52:19 <felixfontein> if you depend on that collection, then you should set up CI so it runs against the latest released version of that collection as well
18:52:33 <acozine> if they are active maintainers they will be in regular contact with the rest of the community, including the folks who develop the common collection, right?
18:52:38 <felixfontein> even if it is non-voting, but you should monitor it and adjust your collection ASAP
18:52:49 <felixfontein> (even better: test against ansible.netcommon's main branch)
18:53:02 <andersson007_> monitoring is hard
18:53:15 <felixfontein> also GHA is making GHA monitoring hard
18:53:38 <samccann> yeah.. just feels there's a corner case here. if your collection really is a set of common tools, breaking those tools for everyone else is like breaking an API.
18:54:14 <samccann> but agreed, setting up CI to detect this is definitely someting dependent collection owners should (possibly MUST) do
18:54:18 <felixfontein> samccann: theoretically they can only break when doing a new major release due to semver, but of course in real life... :)
18:54:36 <andersson007_> real life is hard
18:54:49 <andersson007_> at least in collections
18:54:52 <felixfontein> we probably should extend the requirements so that collections with dependencies do more testing against newer versions of their dependencies
18:55:13 <samccann> +1
18:55:14 <andersson007_> hard to control, i think
18:55:28 <resmo> o/
18:55:29 <andersson007_> but we could mention it of course
18:55:37 <felixfontein> andersson007_: it's definitely hard to control, but if they screw up it's *realy* their fault and nobody can complain to us ;)
18:55:40 <felixfontein> #chair resmo
18:55:40 <zodbot> Current chairs: acozine andersson007_ dmsimard felixfontein gundalow resmo samccann
18:55:48 <andersson007_> felixfontein: true:)
18:55:55 <felixfontein> most of our requirements are hard to control, but we still have them :)
18:56:17 <andersson007_> agreed
18:58:08 <felixfontein> ok, time's almost up
18:58:22 <felixfontein> please also comment in https://github.com/ansible-community/community-topics/issues/94 and https://github.com/ansible-community/community-topics/issues/96 :)
18:59:43 <felixfontein> any last words for this meeting?
19:00:48 <felixfontein> thanks everyone!
19:00:49 <felixfontein> #endmeeting