Versioning of ansible-core dependency for the ansible package

[dmsimard]

Summary

The ansible package has a dependency on the ansible-core package.

Currently, whenever a new release of ansible is made, it's dependency on ansible-core is bumped to the latest release.

For example:

• ansible 5.0.1 has a dependency on ansible-core>=2.12.0
• ansible 5.1.0 has a dependency on ansible-core>=2.12.1
• ansible 5.3.0 has a dependency on ansible-core>=2.12.2
• ansible 5.5.0 has a dependency on ansible-core>=2.12.3

Is this necessary ?

In other words:

• Could every release of ansible 5.x depend on ansible-core>=2.12.0 ?
• Could every release of ansible 6.x depend on ansible-core>=2.13.0 ?

This would slightly simplify how we build the package while making it easier to package downstream.

For example, in Fedora, we bumped into an issue where we couldn't yet build ansible 5.5.0 because ansible-core 2.12.3 had not yet been built and released to stable repositories but 2.12.2 was there and available.

[briantist]

Although I agree with the sentiment, and I feel like it'd be fine not to pin on patch versions, in your last example, would you have wanted to build that even though the resulting 5.5.0 package would not strictly have been the same as what 5.5.0 is intended to be (differing core versions)? It seems like it would be confusing if Fedora's Ansible 5.5.0 package exhibited bugs that were fixed in 2.12.3, and listed as fixed in 5.5.0's changelog.

I have very little context on the packaging stuff, and maybe I'm wrong about the changelog, but still seems iffy to me to have a package advertised as 5.5.0 that will differ in functionality from pip 5.5.0.

I really am asking out of curiosity though, I don't feel I have enough knowledge to say for sure.

[felixfontein]

Also ansible-core contains ansible.builtin, so using an older ansible-core version means you have bugs in modules and plugins from ansible.builtin that should be fixed according to the Ansible changelog. (There are no new features in ansible-core, so at least there won't be options that the docsite documents that aren't there.)

[felixfontein]

See also ansible-community/antsibull-build#94 and https://meetbot.fedoraproject.org/ansible-community/2020-07-01/community_working_group_meeting.2020-07-01-18.04.html, when we originally decided on the current way.

[mariolenz]

For example, in Fedora, we bumped into an issue where we couldn't yet build ansible 5.5.0 because ansible-core 2.12.3 had not yet been built and released to stable repositories but 2.12.2 was there and available.

The collections that are part of Ansible are usually tested against a current version of ansible-core. So IMHO it makes sense to have a a dependency on a current version of ansible-core, too. Your suggestion would mean that it's possible to run Ansible 5.5.0 with ansible-core 2.12.0 and most (if not all) included collections have never been tested against this.

Looks like an accident waiting to happen, if you ask me.

[felixfontein]

@mariolenz that was actually one of the arguments from the discussion almost two years ago ;-) I'll repaste them here (pro = keep current scheme, con = change):

• Pro: changelog included in the latest ansible-2.10.x will be for the latest ansible-base
• Pro: most collections will test against the latest ansible-base-2.10.x
• Con: Prevents users from choosing to use the ansible packaged collections with an older version of ansible-base.

The point on collections also includes the docsite. It currently documents the latest Ansible release with the latest ansible-core release available when the Ansible release happened. If we drop the patch level dependency, this is gets more inaccurate, especially when later in the release cycle.

[jamescassell]

I remain in favor of relaxing the patch-release dep requirement and just use the major version.

[acozine]

I'd be okay with building distro-specific packages on the latest available ansible-core 2.x release in that distro. I'm not so sure about setting up all our workflows around 2.x.0, though. Would that have security implications? What happens when a security vulnerability is patched in Ansible 2.13.4?

[mariolenz]

@felixfontein What about using the ansible-core requirements of the collections for the ansible package defined in meta/runtime.yml (thanks again for the information @dmsimard)?

In the current example (we couldn't build ansible 5.5.0 because ansible-core 2.12.3 had not yet been built although ansible-core 2.12.2 was there):

• Pro: Don't run into the problem that all included collections are fine with ansible-core 2.12.2, but the ansible package requires 2.12.3
• Con: I'm not sure if collections really manage the ansible-core dependency in meta/runtime.yml
• Con: If there's a problem with ansible-core 2.13.0 that's fixed in 2.13.1 and backported to 2.12.4, a requirement of ansible-core >= 2.12.4 would be fulfilled by the problematic release 2.13.0

So, all in all, I'd stick to depending on the latest ansible-core version when releasing the ansible package.

[felixfontein]

@felixfontein What about using the ansible-core requirements of the collections for the ansible package defined in meta/runtime.yml (thanks again for the information @dmsimard)?

I don't think that would be a good idea, since the ansible-core version used has an impact on which features are available. So if someone uses ansible-core 2.11 with the collections from Ansible 5, some features will not be available. The most obvious is the ansible.builtin 'collection', but there are also lots of things indirectly provided by ansible-core through doc fragments and module_utils. (For example, see default_value and trailing_separator for the keyed_groups option of quite a few inventory plugins, for example https://docs.ansible.com/ansible/5/collections/community/general/linode_inventory.html#parameter-keyed_groups.)

[samccann]

The porting guide on docs.ansible.com pulls in the core porting guide as well. So Ansible 5.5.0 would have the porting guide entries from 2.12.13, whereas the user of the distribution package might have 2.12.12. So again, that idea of a security patch would potentially say 'fixed' for 5.5.0, but wouldn't really be fixed for the distribution versoin of 5.5.0.

[MarkusTeufelberger]

Well, if I run pip3 install ansible==5.5.0 today, it will install ansible-core==2.12.5, not 2.12.3 so the changelog at https://github.com/ansible-community/ansible-build-data/blob/8d0292acbc30a3da5457f2ffed57505e13fa625f/5/CHANGELOG-v5.rst#L1278 is also a lie by now. Either there is a fixed version of ansible-core for every release of ansible or there isn't. If there is, it should be fully pinned (including transitive dependencies like jinja2, PyYAML etc.) to make sure that the package stays the same, if dependencies are more flexible according to SemVer ansible-core>=2.12.0 should be good enough for any 5.x release.

[Andersson007]

let's close the topic as there's no activity, thanks everyone! (feel free to speak up or just re-open it if needed)