Looks like centos-10-stream has ansible-core-2.16.3 currently. Do we have any sense if they will stick with this/update to 2.16.10?

In any case we should push the matching ansible version to 2.16.3 for now I guess.

(In reply to Kevin Fenzi from comment #1)
> Looks like centos-10-stream has ansible-core-2.16.3 currently. Do we have
> any sense if they will stick with this/update to 2.16.10?

(As the requester,) I have no idea.  I don't see anything in issues.redhat.com that suggests ansible-core will be uplifted, but that is probably a legitimate question to ask there, if you wish.

> In any case we should push the matching ansible version to 2.16.3 for now I
> guess.

(As the requestor,) I am happy to wait until you get a response for any query you make on issues.redhat.com.  My goal is to be able to use ansible by RHEL10 release time (2025H1?), and a stretch goal would be to be able to use ansible when C10S is available (2024Q4?).

Thanks.

Looks like that would be ansible 9.2.0 - which is commit 9fc79dd8929800c01ab7542c4a9bd820c4945f20 in the ansible dist-git repo.  I had to make the following change to that:

diff --git a/ansible.spec b/ansible.spec
index 54db59e..a6434a6 100644
--- a/ansible.spec
+++ b/ansible.spec
@@ -24,8 +24,8 @@
 %global __brp_mangle_shebangs_exclude_from ^%{python3_sitelib}/ansible_collections/[^/]+/[^/]+/roles/[^/]+/(files|templates)/.*$
 %global __requires_exclude_from %{?__requires_exclude_from:%__requires_exclude_from|}%{__brp_mangle_shebangs_exclude_from}

-%if 0%{?rhel} >= 8
-# ansible-core package is built against Python 3.11 in RHEL 8 and RHEL 9 which
+%if 0%{?rhel} == 8
+# ansible-core package is built against Python 3.11 in RHEL 8 which
 # is not the default version.
 %global python3_pkgversion 3.11
 %endif

as RHEL9 * 10 do use the default python.  With that it built and installed fine.

I'm not a part of the ansible package at the moment so I can't request an epel10 branch.  Happy to join if that's okay.

Subscribing. I have started upgrading some machines to EL10 and the flatpak modules are not in ansible-core

(In reply to Kevin Fenzi from comment #1)
> Looks like centos-10-stream has ansible-core-2.16.3 currently. Do we have
> any sense if they will stick with this/update to 2.16.10?
> 
> In any case we should push the matching ansible version to 2.16.3 for now I
> guess.

Hi Kevin,

We are now 2 months later, and rather close from an official CentOS 10 Stream release (normally in a week). On Red Hat side, ansible-core is still using version 2.16.3 and I see no pending pull request here that would bump it: https://gitlab.com/redhat/centos-stream/rpms/ansible-core/-/tree/c10s So it seems that assuming version 2.16.3 will make it in the first release of CentOS 10 is a right assumption for now.

Cheers,
Romain

So, I am not at all sure this is a good idea. 

rhel is going to stick with 2.16.x it seems, which is fine for them, but... ansible is only supported 6 months upstream.

https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html

ansible 9.x (which is paired with ansible-core 2.16.x) is going eol... this month.

I think instead for epel10 perhaps we could do particular collections that are needed/desired? We may still run into problems with compatibility, but working with one collection to fix something seems a lot more doable than trying to patch a very large ansible collection of collections (and if we change versions of things, it's not really that collection version).

Thoughts?

Yeah, I completely agree with Kevin here.

To summarize, the Ansible community package has a short lifecycle (although I campaigned to double Ansible 9's maintenance from six months to one year, but that's still not long enough for EPEL 10 purposes), and we'd need to maintain a single major version of the Ansible community package that corresponds to RHEL's ansible-core package's major version for ten years downstream. Backporting upstream bugfixes and security fixes for such a large package (the Ansible community package contains over 100 different collections) with no upstream support is infeasible.

Branching the individual ansible-collection-* packages is definitely a more sensible approach. Feel free to file requests for those. In case users need other collections that are not individually packaged, those would have to first be packaged for Fedora.

For the ansible-collection-* packages I maintain, I am looking for co-maintainers, especially for the EPEL branches, as I am currently a bit overcommitted.

I didn't understood initially your proposal Kevin, but now with Maxwell it's clearer to me. And it makes sense to me as well (from the user point of view). I don't know what are the needs at large of all Fedora/EPEL users, but in my case I know I use pretty much only community.general as an extra collection on top of the core ansible.

It can be expected that the core version will bump to the next one or not (2.16 -> 2.17)?? At least this happened in C9S 2.12->2.13->2.14 ...

They changed the procedure in RHEL, so no, these version bumps will not happen anymore. EL 10 is expected to stay at the same ansible-core 2.xx version for its entire lifecycle.