Description of problem: ansible.posix.firewalld fails to load Version-Release number of selected component (if applicable): * ansible-core-2.12.2-3.1.el8 * ansible-collection-ansible-posix-1.3.0-5.el8 How reproducible: Steps to Reproduce: 1. Install latest ansible package dnf install ansible-core-2.12.2-3.1.el8 ansible-collection-ansible-posix-1.3.0-5.el8 2. Create sample ansible playbook that uses ansible.posix.firewalld cat << EOF > firewall.yml - name: Test ansible.posix.firewalld hosts: localhost tasks: - name: permit traffic in default zone for http service ansible.posix.firewalld: service: http permanent: yes state: enabled EOF 3. Run playbook ansible-playbook firewall.yml Actual results: fatal: [localhost]: FAILED! => {"changed": false, "msg": "Python Module not found: firewalld and its python module are required for this module, version 0.2.11 or newer required (0.3.9 or newer for offline operations)"} Expected results: ansible-playbook completes successfully Additional info: Looks like ansible 2.12 is now using python3.8, however the python3-firewall package uses python 3.6. Presumably python3-firewall needs to be updated to python 3.8 or a new python38-firewall needs to be created ? Also, should python3-firewall be a dependency of ansible-collection-ansible-posix ?
Please take a look at my reply to a similar bug (https://bugzilla.redhat.com/show_bug.cgi?id=2091684#c3), and let us know if that solves your problem. We don't want to depend on python38-firewall (even if it did exist) for two reasons: 1. Ansible has a lot of optional dependencies and if we depended on all of them, the package would balloon. 2. This Python module is required on the target node that executes the module, not the controller. In your case, that's the same, because you're running against localhost, but that's not always the case.
Thank you, that is helpful and using 'ansible_python_interpreter' ( or alternatively using 'interpreter_python' in the [defaults] section of ansible.cfg) works. Its just it would be nice if these things worked out of the box. If at least the package python38-$MODULE existed, that would be a step forward, and it's effectively the same thing the reporter of https://bugzilla.redhat.com/show_bug.cgi?id=2091684 asked for. https://bugzilla.redhat.com/show_bug.cgi?id=1932650#c1 suggests that adding bindings for different versions of python is not feasible, but it does not provide detail as to why it's not feasible, perhaps that would help.
@joaocosta, are you relying on implicit localhost[1] or is localhost actually present in your ansible inventory? [1]: https://docs.ansible.com/ansible/latest/inventory/implicit_localhost.html
Both. The example I used in this ticket relies on the implicit definition of localhost as there is no inventory. In the real life code where i first came across this, localhost is defined in the inventory file.
I looked into this a little further. The correct solution here is to run the modules on the target node using the default system python interpreter (/usr/libexec/platform-python for RHEL 8) for which python3-firewall is already packaged. Ansible is supposed to detect the correct python interpreter, but this does not happen in a couple cases. One of these is when you are using implicit localhost. If you are, you will need to add localhost to your inventory, as ansible does not discover the correct system python interpreter when using implicit localhost. According to the ansible docs[1], this is intentional. In any case, this package only contains a bundle of collections, while ansible-core contains the core engine, so there's nothing we can do about that here. [1]: https://docs.ansible.com/ansible/latest/inventory/implicit_localhost.html The other case occurs when the target is running a EL 8 distribution besides RHEL, CentOS, or Oracle Linux (e.g. Rocky or Almalinux). I suspect this is the issue in your case, given that you claimed this even occurs when the target(s) are explicitly defined in your inventory. As I already said, you can get around this by manually setting ansible_python_interpreter to /usr/libexec/platform-python in your inventory. I have asked the RHEL ansible-core maintainers to backport the upstream patch that fixes this issue. > If at least the package python38-$MODULE existed, that would be a step forward Packaging python38-firewall wouldn't really get us any further. This would create extra work for the maintainers with no real benefit, and we'd have to package it again for python39 when RHEL rebases ansible-core to 2.13.x.
Indeed, I ran it on Rocky (should have mentioned it earlier), and that is a really useful insight, thank you for that. I looked into it and from what I can gather, ansible interpreter discovery(https://docs.ansible.com/ansible/latest/reference_appendices/interpreter_discovery.html#interpreter-discovery) relies on a lookup table (https://github.com/ansible/ansible/blob/devel/lib/ansible/config/base.yml#L1532), which as it stands, does not include an entry for Rocky Linux. I can understand your points better now, it would seem to make more sense to have ansible python interpreter auto-detection work in the particular OS, and failing that, configure the python interpreter through the ansible_python_interpreter variable, which as I confirmed before, works, but adds a burden of configuration to something that could just work. Thank you for the time you have spent on this, it has been helpful.
(In reply to Maxwell G from comment #5) > ... can get around this by manually setting ansible_python_interpreter to > /usr/libexec/platform-python in your inventory. I have asked the RHEL > ansible-core maintainers to backport the upstream patch that fixes this > issue. Is there a link/reference to either "the upstream patch" and/or the ansible-core backport ticket (if one exists).
> Thank you for the time you have spent on this, it has been helpful. You're welcome! I'm glad I was able to help. > Is there a link/reference to either "the upstream patch" and/or the ansible-core backport ticket (if one exists). Here[1] is where I asked asked the RHEL ansible-core maintainers to backport the fix. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2093105#c4 I'm closing this as CANTFIX, because there's nothing else we can do here. Let us know if you come across any other issues.