RFC: Cost/benefit of Ansible version constraint ("Your Ansible version (%s) is too recent ...")

[moreati]

This issue is intended for discussion of

1. Should Mitogen continue to check for Ansible versions?
2. If so, how should Mitogen perform such checks?
3. If so, how should Mitogen act on such checks?

Current behaviour

Mitogen currently checks the Ansible version at import time. If it is outside a known, tested range (e.g. 2.10 - 2.18 (11)) then Mitogen intentionally raises an unhandled exception, aborting execution. The associated error message is

Your Ansible version (<major>.<minor>) is too recent. The most recent version supported by Mitogen for Ansible is <major>.<minor>.x. Please check the Mitogen release notes to see if a new version is available, otherwise subscribe to the corresponding GitHub issue to be notified when support becomes available.

Mechanism

The check is performed by ansible_mitogen.loaders.assert_supported_release(), the first time that module is imported.

Costs

There is typically a lag between a new Ansible release, and a corresponding Mitogen release. Some of these have been many months apart. This is disruptive and makes it harder to use Mitogen.

Mitigations

Debian has previously patched the version check to cover periods when no Mitogen release supported the Ansible version shipped with Debian.

The Ansible collection serverscom.mitogen includes a mechanism to patch out or bypass this check.

Benefits

Mitogen's Ansible support uses (abuses) internal Ansible implementation details in order to work. These are not stable between Ansible releases so there is potential that Mitogen would cause errors when used with a new release of Ansible. If that error was not immediately apparent it could cause knock on errors. Teh version check tries to prevent this following the principal of fail fast

a fail-fast system is one that immediately reports at its interface any condition that is likely to indicate a failure. Fail-fast systems are usually designed to stop normal operation rather than attempt to continue a possibly flawed process

Possible behaviours

This list is non-exhaustive, not mutually exlcusive, and in no particular order. Suggestions, questions, comments, and other contributions are sought from anyone

• Remove the check
• Leave the check as is
• Downgrade the exception to a warning, or lower
• Raise a more specific exception/event, so it is easier to catch/handle
• Remove just the upper bound check
• Make it configurable
• Move it to an install time check (e.g. something in setup.py)
• Change the distribution mechanism (e.g. Ansible collection)
• Key the check on Ansible version (e.g Ansible 11) instead of ansible-core (e.g. 2.18)
• Key the check(s) on feature detection, not on version(s)
• Display the Ansible version in any message, as well as or instead of the ansible-core version

Possibly interested parties

• @amarao - maintainer of the Galaxy collection https://galaxy.ansible.com/ui/repo/published/serverscom/mitogen/
• @stefanor - maintainer of Mitogen Debian packages (related Investigate/incorporate/collaborate on Debian packaging & testing #1203)