18:00:02 <felixfontein> #startmeeting Ansible Community Meeting
18:00:02 <zodbot> Meeting started Wed Jun 21 18:00:02 2023 UTC.
18:00:02 <zodbot> This meeting is logged and archived in a public location.
18:00:02 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
18:00:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:02 <zodbot> The meeting name has been set to 'ansible_community_meeting'
18:00:02 <felixfontein> #topic Agenda https://github.com/ansible/community/issues/679
18:00:04 <felixfontein> Landrash[m], Leo[m], acozine, andersson007_, anwesha, ascherbaum, baptistemm, bcoca, briantist, cidrblock, cyberpear, cybette, dericcrago, dmsimard, felixfontein, geerlingguy, gotmax, gundalow, gwmngilfen, ikhan_, jillr, jtanner, lmodemal, mariolenz[m], markuman, maxamillion, misc, nitzmahone, ompragash, oranod, resmo, russoz, samccann, thaumos, wbentley15[m], zbr: The Ansible community
18:00:11 <felixfontein> meeting is starting now!
18:00:13 <felixfontein> The ping list is stored at https://kutt.it/meeting-people. Feel free to add or remove yourself.
18:00:16 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/679 / Topics: https://github.com/ansible-community/community-topics
18:00:19 <felixfontein> #topic Updates
18:00:49 <gotmax23> .hi
18:00:50 * gotmax23 is here but very stressed and preoccupied
18:00:50 <zodbot> gotmax23: gotmax23 'Maxwell G' <maxwell@gtmx.me>
18:00:53 <felixfontein> #chair gotmax23
18:00:53 <zodbot> Current chairs: felixfontein gotmax23
18:00:58 <cybette_> o/
18:01:05 <felixfontein> #chair cybette_
18:01:05 <zodbot> Current chairs: cybette_ felixfontein gotmax23
18:01:20 <oranod> o/
18:01:22 <oranod> hello hello
18:01:27 <felixfontein> #chair oranod
18:01:27 <zodbot> Current chairs: cybette_ felixfontein gotmax23 oranod
18:01:31 <anwesha[m]> I will skip the meeting today. Just landed in Stockholm.
18:01:31 <gotmax23> 🌊
18:01:46 <felixfontein> anwesha[m]: have a great evening then!
18:03:05 <cybette_> #info ansible-core 2.14.7 released https://groups.google.com/g/ansible-devel/c/K1NeeD5Ws_0
18:03:14 <felixfontein> #info community.general is (probably as the first collection that's included in Ansible) starting to use semantic markup
18:03:16 <cybette_> #info ansible-core 2.15.1 released https://groups.google.com/g/ansible-devel/c/CNsM5RRFMHI
18:05:03 <mariolenz[m]> o/
18:05:08 <felixfontein> #chair mariolenz[m]
18:05:08 <zodbot> Current chairs: cybette_ felixfontein gotmax23 mariolenz[m] oranod
18:06:04 <samccann> o/
18:06:27 <samccann> woot for semantic markup fun!!!
18:07:17 <felixfontein> #chair samccann
18:07:17 <zodbot> Current chairs: cybette_ felixfontein gotmax23 mariolenz[m] oranod samccann
18:07:26 <felixfontein> is there something you all want to discuss today?
18:08:02 <felixfontein> one of the more annoying things for me right now is GHA contention (https://github.com/ansible-community/community-topics/issues/237), but I'm not really sure what we can discuss there
18:08:15 <felixfontein> it's not that we want to convince folks to delete tests so CI goes faster ;)
18:08:59 <samccann> heh
18:09:08 <samccann> it is good to remind us that it's a sour spot tho
18:09:58 <gotmax23> It involves RH dealing with vendors, so I assume it'll take a little while ;)
18:10:03 <felixfontein> in gh.com/ansible-collections it's sometimes waiting for *hours* until CI jobs are actually started, especially in the European morning, but since some time also in the evening and on the weekend
18:10:11 <samccann> yeah it is being discussed internally
18:11:03 <felixfontein> yeah, that's why it doesn't really make sense to discuss it here as well, except if someone has solutions that do not depend on "RH does xxx" ;)
18:11:48 <gotmax23> Could we offload more things to AZP?
18:12:45 <felixfontein> not sure, AZP needs more setup (and potentially explicit enablig on RH's side?), and we cannot really use it for EOL versions of ansible(-base|-core)
18:13:31 <felixfontein> hmm, which reminds me of... we really need to discuss what to do with EOL versions of ansible(-core|-base), resp. with collections supporting them
18:14:05 <felixfontein> dropping support requires a major version bump, which most collections do only seldomly, and even then the question is whether support should be dropped or not
18:14:21 <mariolenz[m]> I can live with the GHA contention at the moment. I have far more problems with Zuul. Look at https://github.com/ansible-collections/community.vmware/pull/1593 how often I had to recheck until it succeeded. This really sucks. And it looks like nobody is responsible for Zuul at the moment, at least there's nobody responsible active in the Ansibe Zuul room / channel.
18:15:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:15:14 <gotmax23> We use Zuul in Fedora and I still barely understand how it works
18:15:15 <felixfontein> mariolenz[m]: I guess that also means that more collections will switch from Zuul to GHA (resp. move parts of testing there), which makes GHA even slower for everyone
18:16:07 <gotmax23> Perhaps we should ask the network team to halt those efforts until this figured out?
18:16:59 <felixfontein> I mainly know that the zuul instance that we use takes a long time to set up new VMs to run tests in; it feels (at least for smaller tests, like collection build/import) that a large amount of the (long) runtime is spent in setting up (and tearing down) VMs...
18:17:32 <mariolenz[m]> felixfontein: Not in this case. I've moved sanity tests and similar to GHA, but I don't know how to move the integration tests there. But, yes, if I find a way to do this it would make GHA even slower.
18:18:36 <felixfontein> mariolenz[m]: integration tests that require some services to be present are always hard to port :)
18:20:03 <felixfontein> gotmax23: I'm torn on that one... a) they want a working and supported test environment as well, b) I have no idea how long this will need, c) them moving their tests now makes the siutation worse, which hopefully decreases the time it takes to find a solution since it also slows down RH paid teams :)
18:20:50 <felixfontein> #topic GHA contention
18:21:02 <felixfontein> since we're talking about it anyway... :)
18:21:11 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/237
18:21:51 <samccann> did anyone post in that topic that networking collection owners are starting to move to GHA (and thus the situation will get worse and worse?)
18:22:03 <samccann> just so's there's one place that has all the wrinkles listed
18:22:25 <felixfontein> I just heard rumours about it, I don't really *know* that they do it
18:23:26 <mariolenz[m]> gotmax23: I don't understand everything in Zuul, either. However, my problem is that I don't get any any help and even when I think I understand things I don't get anyone to work on it ([example](https://github.com/ansible/ansible-zuul-jobs/pull/1805)).
18:23:47 <felixfontein> at least ansible.netcommon seems to mostly use GHA at the moment: https://github.com/ansible-collections/ansible.netcommon/pull/553#issuecomment-1599147589 lists only three tests on Zuul, while the list of GHA tests is long
18:23:50 <acozine> o/
18:24:01 <felixfontein> #chair acozine
18:24:01 <zodbot> Current chairs: acozine cybette_ felixfontein gotmax23 mariolenz[m] oranod samccann
18:25:01 <felixfontein> mariolenz[m]: hmm, that's quite problematic, especially since it also results in your collection not being compliant to the Ansible inclusion requirements :)
18:25:12 <felixfontein> (don't worry, you're safe, we know you tried ;) )
18:26:12 <felixfontein> actually the PR I linked is kind of funny, I fixed the link to the correct zuul instance in the "zuul gated" badge, and the PR was merged manually and not by Zuul...
18:26:18 <felixfontein> I just realized now...
18:26:29 <felixfontein> maybe the PR should have removed the badge instead
18:27:46 <gotmax23> Well, it looks like the repo configuration requires that pipeline to pass in order to merge
18:28:42 <felixfontein> gotmax23: the 'gate' job will only run if someone with privileges adds the 'gate' label to the PR - so basically it's waiting for someone to press a button
18:30:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:30:09 <mariolenz[m]> <felixfontein> "mariolenz: hmm, that's quite..." <- Where exactly? I don't see it... and I can't fix what I don't understand. We don't have to discuss this here, ping me directly or open an issue in communtiy.vmware.
18:31:01 <felixfontein> mariolenz[m]: I mean tests not running with all supported versions of ansible-core, especially not the latest version...
18:32:23 <felixfontein> #topic How many versions of ansible(-core|-base) should collections support?
18:32:39 <mariolenz[m]> But that's not integration tests, is it? it's unit and sanity tests... and community uses GHA to run those.
18:32:41 <felixfontein> my earlier question phrased differently
18:33:41 <felixfontein> mariolenz[m]: yes, I wasn't really serious...
18:33:50 <felixfontein> what do folks think about this one?
18:34:23 <bcoca> ^ i assume you mean 'how many should they support to be included in ansible community package' ?
18:34:26 <felixfontein> quite some collections still support Ansible 2.9, and some of them mainly because they didn't had a new major release for some years now (since nothing else came up that's a breaking change)
18:34:55 <felixfontein> bcoca: for that they only need to support the non-EOL versions of Ansible, which is right now only 2.15 and 2.14 (and that one for only one more day)
18:35:22 <felixfontein> s/non-EOL versions of Ansible/ansible-core versions included in non-EOL verisons of Ansible/
18:35:40 <felixfontein> or "included" to make some folks happy
18:36:38 <felixfontein> for how long is RH still providing paid support for Ansible 2.9? (or is it fully EOL already?)
18:37:48 <gotmax23> I believe until RHEL 7 is EOLed later this year
18:37:49 <samccann> I haven't checked in a while but I thought it was through nov. this year?
18:38:16 <gotmax23> It's also still available in EPEL 7. We announced we'd retire it, but then never actually did :).
18:40:03 <felixfontein> I don't think collections should keep supporting it forever just because you can get paid support somewhere though... except if a collection knows its users still actively use it
18:40:23 <felixfontein> I still have no idea which versions to drop support for, though. some folks still use ansible-base 2.10 for some reason
18:40:38 <bcoca> i know people using 1.9 ...
18:40:41 <felixfontein> at an Ansible meetup this year I saw someone give a demo with ansible-base 2.10...
18:40:54 <bcoca> ^ i pretend not to ...
18:41:59 <felixfontein> I think 2.10 is the first version that emits warnings when collections claim to no longer support it, isn't it?
18:42:19 <felixfontein> (using the `requires_ansible` field in meta/runtime.yml)
18:42:28 <mariolenz[m]> I don't care how many versions of ansible(-core|-base) collections support. I think it's up to them. If they are integrated in the Ansible community package, they have to support  the ansible-core version it's based on. 2.15.0 or 2.15.1 soon. But if they still support ansible 0.1beta, that's there choice.
18:42:56 <cybette_> AAP 1.2 (with ansible 2.9) has maintenance support until 29 September 2023 https://access.redhat.com/support/policy/updates/ansible-automation-platform
18:43:54 <felixfontein> mariolenz[m]: I know, but some guidelines on what to support would be helpful. I seriously have *no* idea which versions I should support for 'my' collections
18:44:31 <felixfontein> community.general right now requires ansible-core 2.11+, for example... should it drop support for 2.11? or also for 2.12? or even more? and when?
18:45:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting
18:45:04 <felixfontein> (community.general is sufficiently general that quite many folks will use it, with very different ansible-core versions)
18:50:21 <samccann> thinking out loud... if say community.general stopped support for 2.11, 2.12 in the next major release...
18:50:36 <samccann> that would mean anyone on 2.11 would just use an older version of community.general, right?
18:50:42 <felixfontein> yes
18:50:42 <samccann> like not the end of the world?
18:50:55 <samccann> they;d just be EOL all over ;-)
18:51:06 <felixfontein> well, they will get no new features, and after some more time they won't get bugfixes as well
18:51:12 <felixfontein> true :)
18:51:35 <acozine> maybe those people would step up and offer to backport security fixes themselves?
18:52:10 <felixfontein> which requires us to keep CI working for old versions as well, and do releases for them
18:52:36 <samccann> So it seems like we need two things -
18:52:40 <bcoca> CI has a cost, this cost multiples 'per version' (reason why core is soo stingy with python and OS versions)
18:52:43 <felixfontein> right now for c.g, we keep three stable branches active at the same time (the others are totally EOL without CI and new releases and further updates)
18:52:51 <samccann> 1 - general guidelines on when a collection owner should consider dropping EOL core versions
18:52:59 <samccann> 2 - what specific collection like c.g should do
18:53:38 <felixfontein> or even: 3 - recommendations on whether / how often to do major releases to be able to drop support for EOL core versions
18:53:59 <acozine> I'm fine with making older versions EOL
18:54:09 <samccann> for #1 - what reason is there to keep eol core version support for an active collection?
18:54:11 <acozine> I feel pretty strongly that folks should get into a rhythm with upgrades
18:54:48 <samccann> yeah I'm leaning that way myself. If you are knowingly on an EOL core version, I don't see a problem with them also ended up on an EOL collection version.
18:54:56 <felixfontein> maybe I should create a specific proposal for community.general - say drop support for all ansible-core versions which are EOL when the next major version is released -, publish it on the Bullhorn, wait 1-2 months, and if nobody has relevant objections, create a SC vote on it
18:55:10 <samccann> yeah that's a good idea
18:55:23 <felixfontein> samccann: the main reasons are "someone still needs this combination" and "dropping support requires a new major release, and we don't plan one"
18:58:07 <felixfontein> bcoca: what's the current plan of dropping Python 2.7 support from core (for targets)? is there already a rough ETA for that?
18:59:29 <bcoca> unsure, still many people using targets with 2.7
18:59:37 <bcoca> we would have killed long ago if we could
19:00:13 <bcoca> 2.7 has been EoL, burried, recovered by archeologists, displayed in museom, stolen, reburried .. yet ... stil living
19:00:19 <felixfontein> dropping support for the last ansible-core version with 2.7 support would be interesting for collections, then you can fully use Python 3.x+ for *everything* :) but I guess that will take some more years...
19:00:27 <felixfontein> it's a zombie
19:00:36 <bcoca> no, zombies can be destroyed
19:00:48 <briantist> couldn't attend today unfortunately, but I can read later, would love to hear if there's any update on the GitHub Actions contention
19:00:56 <bcoca> this is headless highlander
19:01:25 <felixfontein> briantist: there isn't one, sorry :(
19:01:38 <gotmax23> Honestly, Python 2.7 is one of the main reasons I don't contribute much to Ansible collections
19:02:10 <felixfontein> *cough* Python 2.6 *cough*
19:02:30 <gotmax23> Do some still support that?
19:02:45 <gotmax23> I wonder if we should loosen the Collection Requirements about this
19:02:46 <felixfontein> yes :) community.general does, as ansible-core 2.11 still supports it for targets
19:03:12 <gotmax23> If collections want to not support Python 2 and state it explicitly in the README, that should be okay IMO
19:03:22 <gotmax23> felixfontein: 😬
19:03:51 <felixfontein> I sometimes really wonder when was the last time someone used c.g with Python 2.6 outside of c.g's CI
19:04:03 <felixfontein> I hope it's years ago, but I'm afraid it is ... now
19:04:25 <felixfontein> anyway, it's time to end the meeting :)
19:04:34 <gotmax23> RHEL 6 uses 2.6, but that EOLed a couple years ago
19:04:39 <felixfontein> I'll create an issue with the proposal, then we can see what folks say - and if they say anything
19:04:50 <felixfontein> gotmax23: that usually doesn't stop folks from using it
19:04:58 <gotmax23> Some are still providing extended support for it EL 6 though
19:05:05 <gotmax23> felixfontein: Right...
19:05:25 <Leo[m]> arghh, got stuck and missed the meeting
19:05:30 <felixfontein> I wonder how many folks still use RHEL x with x < 6 ;)
19:05:43 <felixfontein> #endmeeting