18:00:00 <felixfontein> #startmeeting Ansible Community Meeting 18:00:00 <zodbot> Meeting started Wed Jul 12 18:00:00 2023 UTC. 18:00:00 <zodbot> This meeting is logged and archived in a public location. 18:00:00 <zodbot> The chair is felixfontein. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions. 18:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:00 <zodbot> The meeting name has been set to 'ansible_community_meeting' 18:00:00 <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:05 <andersson007___> o/ 18:00:10 <felixfontein> meeting is starting now! 18:00:13 <felixfontein> #chair andersson007___ 18:00:13 <zodbot> Current chairs: andersson007___ felixfontein 18:00:15 <felixfontein> The ping list is stored at https://kutt.it/meeting-people. Feel free to add or remove yourself. 18:00:18 <felixfontein> #info Agenda: https://github.com/ansible/community/issues/679 / Topics: https://github.com/ansible-community/community-topics 18:00:21 <felixfontein> #topic Updates 18:00:22 <mariolenz[m]> o/ 18:00:30 <felixfontein> #chair mariolenz[m] 18:00:30 <zodbot> Current chairs: andersson007___ felixfontein mariolenz[m] 18:01:09 * gotmax23 will be here in a couple minutes 18:01:26 <acozine> sorry, I cannot participate today, something is very wrong with one of our systems and I need to be in the triage meeting for it 18:01:38 <felixfontein> acozine: good luck! 18:01:42 <felixfontein> #chair gotmax23 18:01:42 <zodbot> Current chairs: andersson007___ felixfontein gotmax23 mariolenz[m] 18:01:49 <acozine> thanks felixfontein! 18:01:53 <anwesha[m]> Hello folks 18:01:56 <mariolenz[m]> acozine: good luck! 18:02:02 <andersson007___> +1 18:02:04 <felixfontein> #chair anwesha[m] 18:02:04 <zodbot> Current chairs: andersson007___ anwesha[m] felixfontein gotmax23 mariolenz[m] 18:02:19 <samccann> 0/ 18:02:30 <oranod> o/ 18:02:37 <felixfontein> #chair samccann oranod 18:02:37 <zodbot> Current chairs: andersson007___ anwesha[m] felixfontein gotmax23 mariolenz[m] oranod samccann 18:02:43 <oranod> hello 18:02:55 <gotmax> .hello gotmax23 18:02:56 <zodbot> gotmax: gotmax23 'Maxwell G' <maxwell@gtmx.me> 18:03:07 <gotmax23> #chair gotmax 18:03:07 <zodbot> Current chairs: andersson007___ anwesha[m] felixfontein gotmax gotmax23 mariolenz[m] oranod samccann 18:03:08 <Leo[m]> Hi all! 18:03:24 <gotmax> 👋 18:03:49 <felixfontein> #chair Leo[m] 18:03:49 <zodbot> Current chairs: Leo[m] andersson007___ anwesha[m] felixfontein gotmax gotmax23 mariolenz[m] oranod samccann 18:04:44 <felixfontein> no releases this week (except pre-releases), but next week things will happen again :) 18:05:00 <gotmax> Yup :) 18:05:35 * gotmax notes that we released a new version of antsibull a couple days ago 18:05:50 <felixfontein> and antsibull-docs 18:06:05 <felixfontein> #info antsibull-docs 2.3.0 has been released with improved rendering and linting of semantic markup! 18:06:08 <andersson007___> 🎉 18:06:13 <gotmax> Yeah :). There's some good changes in that one. 18:06:29 <felixfontein> also the ansible-core plugin/module docs now use semantic markup (the last PR got merged today) 18:06:35 <andersson007___> thanks for the great work on that! 18:06:40 <gotmax> 🎉 indeed! 18:07:02 <gotmax> Also, the ansible-documentation split out was completed 18:07:14 <felixfontein> right now collection_prep and ansible-language-server are the last (relevant) tools (I'm aware of) that don't have semantic markup support yet 18:07:17 <felixfontein> indeed! 18:07:31 <gotmax> I tagged #243 for meeting, as I had some follow up questions/discussion 18:07:41 <felixfontein> #info the docs/ directory of the ansible/ansible repository has been moved to a separate repository, ansible/ansible-documentation 18:07:46 <gotmax> What's the latest with ansible-language-server? 18:07:57 <mariolenz[m]> Zuul has some problems at the moment. If this doesn't get fixed soon, might we have a problem releasing 8.2.0 next week? 18:08:10 <felixfontein> sounds good. I'd also like to talk about 251 (Update Python requirements for collections included in Ansible) 18:08:11 <gotmax> That was one of the main motivators for the ts version of antsibull-docs-parser, wasn't it? 18:08:30 <felixfontein> mariolenz[m]: hmm, good point, I wonder how that affects collection releases 18:08:33 <felixfontein> did anyone try? 18:09:06 <mariolenz[m]> At least collection releases. Would it also affect the community package? 18:09:06 <felixfontein> gotmax: a PR for ansible-language-server has been merged two weeks ago, but it hasn't been included in a release 18:09:15 <gotmax> Ah 18:09:20 <felixfontein> antsibull-docs-ts is both for ansible-language-server and galaxy_ng 18:09:30 <gotmax> Right 18:10:00 <felixfontein> btw, does anyone knows whether galaxy_ng 4.7.1 is already contained in an AH release? because that's the first version which contains semantic markup support 18:10:35 <felixfontein> mariolenz[m]: I think all community.* collections are built with Zuul. but I think the Ansible community package's build doesn't depend on Zuul 18:10:59 <felixfontein> it would be bad if quite a few collection releases would miss the Ansible release though, just because Zuul isn't working :/ 18:11:23 <felixfontein> community.general 7.2.0 should get released next Monday, assuming Zuul works 18:11:47 <felixfontein> ok, let's start with topics 18:11:59 <felixfontein> #topic Making community docs a separate project to ansible/ansible 18:12:06 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/243 18:12:32 <felixfontein> #info The docs have been split from ansible/ansible to ansible/ansible-documentation, and the Steering Committee has commit rights in that new repository 18:12:42 <felixfontein> gotmax: you said you had something concrete for this topic 18:12:55 <andersson007___> fyi i'm pinging people internally about zuul 18:13:24 <gotmax> Yes :). 18:13:26 <felixfontein> andersson007___: jillr tried to contact the hosting provider, but apparently without success so far 18:13:42 <felixfontein> (see #ansible-zuul) 18:13:42 <andersson007___> ah, ok felixfontein thanks 18:13:53 <gotmax> I wanted to ask about Create tagged releases for stable branches #66 and about the patchback bot issue 18:13:55 <bcoca> ^ tangent: is there a way to add a redirect from the old repo to new location? been looking at github and cannot find such feature outside of github pages (which are already html) 18:14:29 <gotmax> what repo are you referring to? 18:14:30 <oranod> fwiw I was looking and couldn't find anything outside gh pages either 18:14:32 <felixfontein> bcoca: I only know of redirects when you rename the whole repo, but not when you move parts of a repo to another 18:14:41 <mariolenz[m]> andersson007___: https://github.com/ansible-collections/community.vmware/issues/1746#issuecomment-1631130899 18:14:57 <gotmax> Ah that 18:15:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:15:15 <andersson007___> thanks mariolenz[m] 18:15:20 <gotmax> Yeah, I don't think that's possible 18:16:06 <gotmax> The issue I mentioned is asking whether we can tag stable-2.X branches' states after each ansible-core releases 18:16:30 <gotmax> #link https://github.com/ansible/ansible-documentation/issues/66 18:17:20 <felixfontein> I'm wondering when the tag should be created - at the point of when the corresponding tag happens in ansible/ansible, or at the point when the docs for ansible-core are built? 18:17:40 <samccann> we build docs constantly 18:17:46 <gotmax> I was thinking the former 18:18:03 <felixfontein> samccann: do you mean for latest/, or just for devel/? 18:18:11 <samccann> both 18:18:15 <samccann> well I should say 18:18:23 <samccann> I do backports weekly to latest and republish 18:18:54 <samccann> that has been from a stable branch. So in the new repo, I'd publish to Ansible 8.x and core 2.15.x from the stable-2.15 branch 18:19:16 <samccann> weekly (when I'm back in the habit of doing backports weekly again..) 18:19:26 <gotmax> I think this tagging would be best done as part of core's release process 18:20:27 <felixfontein> I guess this is more a question to the core team then, whether they want to integrate this in their release process 18:20:31 <samccann> so the tag for 2.15 happens on the 2.15 branch, for each dot release? 18:20:45 <felixfontein> similar to the tags in ansible/ansible 18:20:54 <gotmax> Exactly 18:20:58 <samccann> I've never tried to 'sync' my backports to cover dot releases. (and never paid attention to tags in ansible/ansible 18:21:12 <gotmax> I don't think anything needs to be synced 18:21:12 <samccann> just so's y'all know :-) 18:21:18 <gotmax> :) 18:21:30 <gotmax> I'd just like to have the current state after each release recorded 18:21:44 <samccann> so keeping the docs tagging in sync with ansible/ansible tagging would be.. keeping the world the way it has been :-) 18:21:51 <gotmax> Right 18:22:26 <felixfontein> I guess this is only interesting for folks who package the documentation, i.e. for OS packagers 18:22:45 <felixfontein> but I agree it makes sense for them, otherwise they have to somehow figure out the commit hash themselves for every release 18:22:51 <gotmax> Yeah, that's my main motivation, but I think it's generally a good idea 18:22:53 <felixfontein> (if they want reproducable builds) 18:24:06 <gotmax> This could be added to https://github.com/ansible/ansible/blob/devel/packaging/release.py 18:24:14 <felixfontein> I would ping the core team in that issue to ask them whether they can integrate tagging in their release process 18:24:24 <gotmax> Yeah, right 18:24:37 <gotmax> I guess I'll ask mattclay who wrote that script 18:25:22 <gotmax> #link https://github.com/ansible/ansible-documentation/issues/41 18:25:23 <felixfontein> ok. you also wanted to discuss the patchback issue/PR? 18:25:27 <gotmax> Yeah 18:25:42 <gotmax> This would definetely be helpful for the ansible porting guides 18:25:54 <felixfontein> I unfortunately didn't manage to be at yesterday's DaWGs meeting 18:26:09 <felixfontein> one question for me is whether this topic is better suited for the DaWGs meeting or for this one :) 18:26:28 <samccann> mostly it was the thumbs-up to remove the docs folder and examples folder in ansible/ansible 18:26:35 * gotmax should probably start coming to the DaWGs meetings 18:26:47 <samccann> (tho the examples folder removal has blown up on us... seems many places were using it and getting 404s now) 18:27:03 <samccann> https://github.com/ansible/ansible/issues/81240 18:27:13 <briantist> o/ (but I'll be in another meeting) 18:27:25 <samccann> and https://github.com/ansible/ansible/pull/81011#issuecomment-1632706339 18:28:37 <gotmax> #info We're looking for feedback in https://github.com/ansible/ansible-documentation/issues/34 about how folks use the `examples` from ansible/ansible-documentation that recently moved from ansible/ansible 18:28:49 <felixfontein> relying on that a repository never moves files in its main development branch is ... naive 18:29:03 <gotmax> I tend to agree... 18:29:32 <oranod> yeah I didn't want to say in my response but relying on anything on a devel branch is risky 18:30:00 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:30:28 <gotmax> You did recommend pinning to a specific commit which is what people should probably have done in the first place :) 18:31:25 <felixfontein> yes, or at least stick to some specific stable branch... 18:31:45 * cyberpear arrives late 18:31:49 <felixfontein> #chair cyberpear 18:31:49 <zodbot> Current chairs: Leo[m] andersson007___ anwesha[m] cyberpear felixfontein gotmax gotmax23 mariolenz[m] oranod samccann 18:31:57 <gotmax> Should we move on to the Python issue or is there anything else here? 18:32:32 <felixfontein> sounds good to me 18:32:57 <felixfontein> #topic Update Python requirements for collections included in Ansible 18:33:10 <felixfontein> #info Discussion: https://github.com/ansible-community/community-topics/issues/251 / first proposal: https://github.com/ansible/ansible-documentation/pull/68/files 18:34:11 <felixfontein> in case anyone missed what happened, in our Ansible collection requirements document (for inclusion in the Ansible package) we were explicitly requiring Python 2 support on the controller, and some other things that weren't really relevant anymore (except if you promise to support old ansible-core versions) 18:34:41 <felixfontein> there has been a PR from core to update that formulation, and apparently it wasn't clear that changes to this document have to go through a voting process 18:35:12 <felixfontein> in any case, we reverted that change for now and created a new PR for it so we can now discuss it. we definitely have to update this part of the requirements, the main question is what exactly we want to change it to 18:35:46 <gotmax> I think we should soften this a little 18:35:52 <felixfontein> one difference between the old version and the proposal (https://github.com/ansible/ansible-documentation/pull/68/files) is that it no longer requires to support all Python versions (unless used libraries prevent it) 18:36:05 <felixfontein> gotmax: soften the original requirements, or the proposal? 18:36:13 <felixfontein> or what I wrote above? 18:36:59 <gotmax> If collections have a good reason for not supporting Python 2.7 that was EOL three years ago for their modules, they shouldn't have to as long as they document it 18:37:14 <felixfontein> so you mean the original proposal? 18:37:22 <gotmax> Yes 18:37:23 <felixfontein> s/proposal/requirements/ 18:37:38 <felixfontein> yes, I fully agree... 18:37:41 <gotmax> It looks like the proposal is line with what I'm saying 18:37:46 <cyberpear> "other environment" is the managed node, right? de facto is that on the controller, python 3 is required, right? 18:37:51 <gotmax> Right 18:38:03 <felixfontein> the proposal basically says "you can support as few or many Python versions as you like, as long as you document it" 18:38:34 <felixfontein> cyberpear: 'other environment' is where the module is executed, which can be both the controller or the managed node 18:38:39 <gotmax> I think I'm happy with that 18:38:48 <Leo[m]> felixfontein: In my view, the question would be what versions are *required* to be supported 18:39:28 <felixfontein> the original intention was that we don't want that collections only stick to the latest versions of Python and abandon all their users which have older OSes where it's hard or impossible to install such Python versions 18:39:36 <gotmax> Maybe we could add some sort of SHOULD or a soft recommendation, but I don't want to force collections to carry huge amounts of compat code forever 18:39:49 <gotmax> and in some cases, necessary libraries don't support 2 at all 18:39:56 <gotmax> s/2/python2/ 18:40:06 <felixfontein> that case was already covered 18:40:13 <Leo[m]> I agree on leaving it up to the maintainer for what they support, I mean, but shouldn't be clear the distinction to be included in the community package which are required? 18:40:17 <felixfontein> "unless required libraries do not support these versions" 18:40:27 <gotmax> Right 18:40:44 <cyberpear> I feel like there should be REQUIRED support for at least as far back as the newest python available on the latest RHEL, and SHOULD for the newest python on non ELS RHEL 18:40:46 <felixfontein> I would be very annoyed if a collection says "we only support Python 3.9, but nothing newer or older" 18:40:53 <felixfontein> which would be allowed by the new rules, as long as they document it 18:41:06 <gotmax> Yeah, I don't like that either 18:41:06 <felixfontein> (if there's a technical reason for only supporting Python 3.9 that would be fine, but if there isn't...) 18:41:50 <felixfontein> but I'm not sure how to write that as a good rule that isn't too restricting 18:42:14 <gotmax> We could say that collections SHOULD support at least the same versions that core does on the controller for modules and plugins 18:42:55 <cyberpear> gotmax++ for SHOULD matching core support 18:42:55 <zodbot> cyberpear: Karma for gotmax23 changed to 7 (for the release cycle f38): https://badges.fedoraproject.org/tags/cookie/any 18:43:04 <mariolenz[m]> I agree, being that specific on the Python version (exactly 3.9) is too narrow. 18:43:05 <felixfontein> maybe something like MUST document which versions are supported, and SHOULD support most of the Python versions that the latest stable ansible-core release supports, and MUST NOT exclude newer (ansible-core supported) Python versions if there aren't good technical reasons for it? 18:44:18 <gotmax> By versions that ansible-core supports, I mean the versions on the controller. So even for modules, they SHOULD at least support 3.9, 3.10, and 3.11. 18:44:25 <Leo[m]> felixfontein: +1, seems a bit complex to follow, but works (I tend to like tables showing versions, an example could help here) 18:44:25 <felixfontein> so saying "we don't support Python 3.11 because the library we need doesn't support it" is OK, or "we don't support Python 3.11 yet because it removed something from stdlib which we really need" is also OK, but saying "we don't support Python 3.11 because we don't want to fix that construct which now is a syntax error" is not OK 18:44:53 <cyberpear> felixfontein++ 18:45:01 <remindbot[m]> @cybette:ansible.im cyb-clock chimes every 15 minutes during the community meeting 18:45:07 <gotmax> Then we could say, something like Collections are recommended to support all versions that ansible-core supports for modules if libraries support those versions 18:45:16 <gotmax> So there'd be a SHOULD and then a softer recommendation 18:45:21 <felixfontein> that sounds good to me 18:45:26 <Leo[m]> felixfontein: following the **should** logic, what happens if they dont support the latest stable ansible-core supported one? 18:45:57 <gotmax> FTR, I agree with felixfontein's python3.11 point 18:46:02 <felixfontein> Leo[m]: you mean ansible-core supports Python 3.12, while foo.bar only supports up to Python 3.11? 18:46:31 <felixfontein> or do you mean foo.bar only supports Python 3.9 and before, while ansible-core 2.16 needs Python 3.10+? 18:46:42 <gotmax> Well, there'd be a SHOULD guideline to support that version, so we should encourage collections, but not make it a hard rule 18:46:53 <Leo[m]> yes, unless that's blocked somewhere else and I missed it 18:47:00 <jtanner> fyi, AAP as a whole is moving to 3.11 soon it's unlikely that "no 3.11 support" is going to fly 18:47:29 <gotmax> RHEL 8 and 9 already use python3.11 for ansible-core 18:47:49 <Leo[m]> jtanner: 3.11 are only examples for the versioning discussion (i think :D) 18:47:56 <jtanner> k 18:48:02 <felixfontein> yes, I just picked some 'random' versions ;) 18:49:42 <Leo[m]> felixfontein: both scenarios are posible with the **should**, or not? are we requiring collections to support the current python version for the current ansible-core matched in the ansible community package somewhere else? 18:50:36 <Leo[m]> (current == next release/devel probably, as the inclusion wont happen mid release, right?) 18:50:42 <felixfontein> Leo[m]: 'SHOULD' always allows exceptions; the good thing is that if we say 'SHOULD' and someone intentionally violates it, we still have a reason to kick them out 18:50:51 <felixfontein> Leo[m]: we don't have any other requirements on Python versions IIRC 18:50:57 <samccann> inclusions do happen mid release I think? 18:51:01 <gotmax> See https://datatracker.ietf.org/doc/html/rfc2119 18:52:00 <felixfontein> samccann: yes 18:52:10 <felixfontein> (though of course they can also happen for X.0.0) 18:52:26 <gotmax> I guess I could file a PR for what I'm thinking 18:52:52 <felixfontein> gotmax: a new PR, or adding a suggestion to the existing PR? 18:52:56 <Leo[m]> I got to review the inclusion docs again, going to stop making noise, maybe what I'm thinking it's already there 18:53:12 <gotmax> I was thinking a new one, but either way I guess 18:53:23 <gotmax> Although I think Leo[m] made a valid point about referring to versions that core supports without listing them 18:53:25 <felixfontein> Leo[m]: re-reading sounds like a good idea... I mostly remember things from memory, and memory tends to not always be fully accurate ;) 18:53:38 <felixfontein> yes, we should definitely not list the versions explicitly 18:53:50 <felixfontein> that part of the PR is great and I really like it :) 18:53:57 <gotmax> It would be nice not to worry about it getting out of sync, but it might be confusing without it 18:54:23 <gotmax> I guess the link to the maintenance/support table is sufficient 18:54:57 <felixfontein> if there is no automatic process which updates it, it will always get out of sync ;) 18:55:46 <felixfontein> would be great if you could create a suggestion for the PR, I think that's the easiest (and it keeps the attribution for adding the link) 18:56:11 <felixfontein> ok, I'm going to switch to open floor 18:56:13 <Leo[m]> gotmax: we can always put an example and a clear notice about it 18:56:15 <samccann> +1 for linking to the existing maint/support table. Core keeps that uptodate 18:56:25 <felixfontein> #topic Open Floor 18:56:29 <gotmax> #action gotmax23 to suggest changes to https://github.com/ansible/ansible-documentation/pull/68/ 18:56:33 <felixfontein> Leo[m]: yes, an explicit example is always great! 18:56:40 <gotmax> +1 18:56:41 <felixfontein> any quick topics for the open floor? 18:57:01 <anwesha[m]> I am working on GHA for the release. 18:57:21 <gotmax> That sounds interesting 18:57:37 <anwesha[m]> * I am working on Github Actions for the release. 18:57:50 <felixfontein> \o/ 18:57:54 <gotmax> https://github.com/ansible-community/ansible-build-data/pull/227 as been outstanding for a bit. not sure what we want to do with that. 18:58:02 <anwesha[m]> Please have a look and share your thoughts https://hackmd.io/rGoXrLCEQ_KGqTsZZtyAeA?edit 18:58:20 <andersson007___> 🎉 18:58:40 <felixfontein> anwesha[m]: do you want to take another look at gotmax's PR, or should we just merge it as a first version of the process? 19:00:42 <anwesha[m]> I will re-review it. 19:00:54 <felixfontein> thanks! 19:01:00 <felixfontein> ok, time to end the meeting :) 19:01:02 <felixfontein> #endmeeting