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