Regression with ansible_pkg_mgr discovery on Amazon Linux 2 about ansible HOT 9 CLOSED

Files identified in the description:

• lib/ansible/modules/setup.py

If these files are incorrect, please update the component name section of the description or use the component bot command.

from ansible.

This is a deliberate removal of functionality, not a regression. As noted in the porting guide Python 2 and the original yum module are no longer supported. If you need to manage systems like Amazon Linux 2 which are not compatible with this version of ansible-core, you should downgrade to a version that does support these targets.

use_backend: yum is supported to (theoretically) allow people to avoid updating their playbooks, though I can't think of a situation where a playbook with yum: use_backend=yum would have worked in the past and continue working now, so it arguably should have just been removed. Since it no longer maps to a specific supported backend the logic falls back to other methods of determining the appropriate backend, and there is no backend that works with AL2 so it's expected that it fails.

from ansible.

This is a deliberate removal of functionality, not a regression. As noted in the porting guide Python 2 and the original yum module are no longer supported. If you need to manage systems like Amazon Linux 2 which are not compatible with this version of ansible-core, you should downgrade to a version that does support these targets.

This project is using Python 3 (see above) and the documentation for the current version of the DNF module being used (see above) says that the yum backend is a valid choice:

By default, this module will select the backend based on the ansible_pkg_mgr fact.

Choices:

"auto" ← (default)
"yum"
"yum4"
"dnf4"
"dnf5"

from ansible.

It's a valid choice, but it doesn't do the same thing it used to, which is select the yum module.. The yum module only worked with Python 2 (because that's the only version the Python bindings in AL2 are built for, regardless of what Python versions are installed on the system) and has been removed.

from ansible.

In that case, there is the original bug (the package manager shouldn't be detected as “unknown”) and the documentation should be updated to remove the unsupported yum option, along with updating the porting guide to note that this removal affects more than just the yum module. The error message in particular is misleading since you still see the same message telling you to set use_backend after having done so.

from ansible.

The package manager is detected as "unknown" because no supported package manager is found. This is not a bug.

The documentation does not need to be updated to remove the option, the yum option is supported. As I said it is arguable whether it should be supported, but it currently is so removing it would not be accurate.

I'm not sure how the porting guide could be clearer, though feel free to propose new wording if you think there's an improvement that can be made.

from ansible.

#83429 updates the documentation for use_backend to be much clearer about what each option means.

from ansible.

Resolved by #83429

from ansible.

The package manager is detected as "unknown" because no supported package manager is found. This is not a bug.

I think updating the documentation to say that Ansible 10 does not support the EL7-era distributions even when running under Python 3 is the right fix but this is a bug by common definitions of the term: Ansible 9 returns the correct output, Ansible 10 does not, and the cause not due to any change to those servers – from a user's perspective, the identical input is now returning an incorrect output. Anyone using Ansible with logic based on the discovered facts will now get incorrect results even for code which would otherwise work (e.g. I have used that fact to run certain configuration command blocks for things which were never supported by the yum module).

I think the update to the documentation is probably sufficient but it might be worth clarifying some of the vagueness: the porting guide and ansible-core's support matrix do say that Python 3.7+ is required but all of those servers I encountered this on have Python 3.8 installed as /usr/bin/python3. What they don't have are the Python bindings which the yum RPM provided for Python 2.7 on distributions of that era. Perhaps the porting guide should explicitly say that the yum functionality not available even when using an otherwise-supported Python version – as currently written, it sounds like a system where Ansible is using /usr/bin/python3.8 would work, or potentially require switching to the dnf module since “redirected” is generally not a term you'd used to say something has been removed without a migration path.

I think it would be useful to make the unsupported aspect easy to discover quickly since package management is such a common use for Ansible and many large organizations will have legacy systems which need to be patched, especially since some distributions will be supported for at least a year from now. I think it would be useful to let people know as early as possible that they'll need to keep Ansible 9 around until those are decommissioned.

from ansible.