mitogen-hq
RFC: Cost/benefit of Ansible version constraint ("Your Ansible version (%s) is too recent ...")
This issue is intended for discussion of
- Should Mitogen continue to check for Ansible versions?
- If so, how should Mitogen perform such checks?
- 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 #1203)
From my PoV, it doesn't make too much difference either way. When a new ansible releases is uploaded to Debian, we'll probably experiment with dropping the constraint, and if there are issues we see we'll fix them.
In Debian, we generally follow the policy of avoiding protective constraints like this, in our own packaging metadata. We don't know what the future holds, but when it comes we'll deal with it. But, our circumstances are different to PyPI. We have a policy of only having one version of any package available in a release at a time (typically the latest version that we can make work). And we have tooling to find regressions in reverse-dependencies when we upload updates.
That tooling will reliably detect issues declared in dependencies (because old mitogen won't be installable any more, when a new ansible is uploaded). And it can pick up issues that are detected in the parts of mitogen's test-suite that we run (not the docker bits).
I'm falling in favour of removing the upper bound check, and maybe also the lower bound.