Issue with check "requires_ansible key must be set to a supported version"

[andy-maier]

Summary

PR #2770 introduced a check for the "requires_ansible" value in meta/runtime.yml. The way it was implemented causes the omission of the patch version now to be reported as an issue. For example:

requires_ansible: ">=2.9"

results in:

meta/runtime.yml:1: meta-runtime[unsupported-version]: requires_ansible key must be set to a supported version. 

The issue is that the page showing supported Ansible versions does not even mention the supported patch versions:
https://docs.ansible.com/ansible/latest/reference_appendices/release_and_maintenance.html . This makes it a try-and-error to even find a patch version that is accepted by ansible-lint. It seems to me that when Ansible itself documents its supported versions without mentioning a patch version, that ansible-lint should not insist on a patch version. Where does ansible-lint gets its notion of supported Ansible versions from?

An additional issue is that when a collection supports Ansible versions that are marked EOL, this issue is raised even when specifying the latest released patch version (e.g. 2.9.27). How can collections that need to support such Ansible versions get rid of this warning?

Issue Type

• Bug Report

OS / ENVIRONMENT

We get this error from the upload check that Ansible AutomationHub performs.

The error does not occur in the upload check that Ansible Galaxy performs, nor in the ansible sanity test on any Ansible version supported by Ansible.

When installing ansible-lint 6.22.1 and running it, it does report the error.

STEPS TO REPRODUCE

Have a meta/runtime.yml file with this content:

requires_ansible: ">=2.9"

Run ansible-lint

Desired Behavior

I think the discrepancy between Ansible's (non-)focus on patch versions and the requirement of ansible-lint to specify the patch version needs to be seriously reconsidered. I don't see the value of specifying a patch version in requires_ansible.

Actual Behavior

See above.

[ssbarnea]

Thanks for reporting this, we identified at least one bug related to the versions checks and there is a patch in progress.

Still, regarding your other question about keeping a collection compatible with an EOL version of Ansible, I am afraid I do not a pleasant answer. AFAIK, now the only workaround is to keep a different maintenance branch for the old version and use a supported version in the current version, which would mean that you need to have a minimum of >=2.14.0 to pass this check. If you look at #3954 you will see some explanations regarding why we ask for a full version number. Shortly just adding .0 should sort the versioning issue.

At this moment most of the checks that historically were done by galaxy-importer are replaced by ansible-lint and the newer importers would make use of linter code directly for checking it.

[alisonlhart]

I'll add on to this and say that the rule details are enforced by Ansible Partner Engineering only for certified and validated collections on Automation Hub, so it is intentional that the rule does not run on Galaxy. This is designed specifically to prevent customers from using unsupported Ansible versions. If you want to still support Ansible 2.9 within the collection itself, you can do so, but it will need to be specified in the README and the "requires_ansible" value will still need to be updated to ">=2.14.0". The "requires_ansible" value is interpreted by customers as a statement of support by both Red Hat and the partner, and Red Hat no longer support any versions below 2.14.

Any questions about the enforcement or the requirement can be directed to our team email [email protected].

Please reach out there and we're happy to discuss further about why this requirement is in place. See our Life Cycle documentation here for more information about EoL versions.

[andy-maier]

@ssbarnea Thanks for the explanations, that makes sense.

We will change the "requires_ansible" value to match the lowest still supported Ansible version, i.e. currently ">=2.14.0", and will describe in our support statement for our collection that Ansible back to 2.9 is tested against and can be used on a best-can-do basis.

You did not answer the question yet what the criteria is for ansible-lint to accept a particular version. The https://docs.ansible.com/ansible/latest/reference_appendices/release_and_maintenance.html#ansible-core-support-matrix
table lists three dates for each version, for example for ansible-core 2.14:

• Critical: 22 May 2023
• Security: 06 Nov 2023
• EOL: 20 May 2024

Can I assume that ansible-lint uses the EOL date?

[alisonlhart]

@andy-maier That is correct. After that EoL date, this rule will be updated with the new set of supported versions.

You can also refer to the "Maintenance Support 2" date (aka the downstream EoL), which is shown in the Life Cycle documentation I previously linked. The documentation you linked is the upstream Ansible documentation, and its EoL date is slightly before the downstream EoL date. Ansible Partner Engineering uses the downstream EoL date as the official date for updating and enforcing certification requirements.

Referring to the downstream Life Cycle documentation is the best way to monitor when this requirement will be enforced for certification, as well as monitoring emails from our Ansible Partner Announce List, where we have been announcing this coming requirement over the past few months.

[andy-maier]

Hi Alison, thanks for the clarifications. This ticket can then be closed.

[andy-maier]

One more comment: I now read the Life Cycle documentation, and it states that AAP 1.2 with Ansible Engine 2.9 is still in an extended support.

The https://docs.ansible.com/ansible/latest/reference_appendices/release_and_maintenance.html#ansible-core-support-matrix states that ansible 2.9 is EOL, though.

I guess we'll link to both documents then in the documentation of our collection.

[alisonlhart]

@andy-maier That's correct, but the AAP 1.2 ELS does not include Ansible Content in its support and is related to the platform support only. For that reason we require 2.14+ for certification, but you're welcome to include that addendum in the documentation!