Due to a change in Python, the version of Python used to run Ansible on Fedora 39 needs to have this patch applied: https://github.com/ansible/ansible/commit/a861b1adba5d4a12f61ed268f67a224bdaa5f835 This is because the readfp() function was removed in Python 3.12. This breaks lookup of local facts in /etc/ansible/facts.d/, as well as the ansible.builtin.ini lookup() function when it uses ansible.builtin.ini. This was reported in: https://github.com/ansible/ansible/issues/81656 For example: $ cat /etc/ansible/facts.d/test.fact [testsection] testentry = test $ ansible -m debug -a "msg={{ lookup('ansible.builtin.ini','testentry section=testsection file=/etc/ansible/facts.d/test.fact') }}" localhost localhost | FAILED! => { "msg": "An unhandled exception occurred while running the lookup plugin 'ansible.builtin.ini'. Error was a <class 'AttributeError'>, original message: 'ConfigParser' object has no attribute 'readfp'. 'ConfigParser' object has no attribute 'readfp'" } $ sudo sed -i 's/readfp/read_file/' /usr/lib/python3.12/site-packages/ansible/plugins/lookup/ini.py $ ansible -m debug -a "msg={{ lookup('ansible.builtin.ini','testentry section=testsection file=/etc/ansible/facts.d/test.fact') }}" localhost localhost | SUCCESS => { "msg": "test" } also, this bug prevents ansible_local from being populated. For example: $ ansible -m setup localhost | grep ansible_local "ansible_locally_reachable_ips": { $ It doesn't even show an empty dictionary. But: $ sudo sed -i 's/readfp/read_file/' /usr/lib/python3.12/site-packages/ansible/module_utils/facts/system/local.py $ ansible -m setup localhost | grep ansible_local "ansible_local": { "ansible_locally_reachable_ips": { Reproducible: Always Steps to Reproduce: 1. Install ansible-core package 2. Create an INI file 3. Use ansible's lookup() function to read that file Actual Results: You get an AttributeError while creating a ConfigParser object: An unhandled exception occurred while running the lookup plugin 'ansible.builtin.ini'. Error was a <class 'AttributeError'>, original message: 'ConfigParser' object has no attribute 'readfp'. 'ConfigParser' object has no attribute 'readfp'" Expected Results: Ansible should be able to read INI files fine.
FEDORA-2023-6787b97c3e has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-6787b97c3e
FEDORA-2023-6787b97c3e has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-6a4cb513e6 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-6a4cb513e6
Let's keep it open until the F39 update is stable. @jbilling Can you please verify whether it fixes the problem for you? (and give +1 karma if it does). Thanks!
Thanks for fixing this, Kevin! I am also planning to rebase the package to 2.16.0b1 tomorrow which actually supports Python 3.12 officially. I do not want to ship our heavily patched version of 2.15 in the final release.
Also, please don't block private bugs or leave private comments on Fedora bugs. We cannot see them and thus cannot do anything about them. Can someone @redhat please remove the Block on bug 2184978 (I don't even have sufficient permissions to remove the Block) or make the bug public?
Tested ansible-core-2.15.4-2.fc39.noarch.rpm, and it works with our playbooks, and correctly pulls ansible_local data and INI file information.
FEDORA-2023-6a4cb513e6 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-6a4cb513e6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-6a4cb513e6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-5f1c7b81cd has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-5f1c7b81cd` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-5f1c7b81cd See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-5f1c7b81cd has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Maxwell G from comment #7) > Also, please don't block private bugs or leave private comments on Fedora > bugs. We cannot see them and thus cannot do anything about them. Can someone > @redhat please remove the Block on Red Hatbug 2184978 (I don't even have > sufficient permissions to remove the Block) or make the bug public? Hi, sorry, no. The bug in question is private because it concerns an internal product. This bug blocks it, so the relationship is correct (keep in mind that those relations are bidirectional - we don't really care about Blocks here, we care about Depends On in the other bug, but you can't have one without the other). But it has no negative impact on this public discussion, everything important is public here, and the fact that an internal product is blocked doesn't really impact anything in Fedora. In other words, you're really not losing any information, and if there was some important information hidden somewhere, I'd reprint the important and relevant parts even in the public section. But there's no such thing in this case. In general, I always make sure that everything that can be public is public, and private flags are used as little as possible.