ansible.utils.ipaddr('private') Failure in Github Runners
pyrodie18 opened this issue · comments
Not sure what changed in the Agent role using the ansible.utils.ipaddr('private') filter is failing and causing all of the workflows to fail.
I also ran into this problem, on my RHEL8 system I was running with the following ansible and netaddr 0.8.0 from EPEL. I saw the exact same error, however, when I moved to 'upstream' netaddr 1.2.1 from PyPI it worked again.
ansible [core 2.15.3]
config file = /etc/ansible/ansible.cfg
configured module search path = ['/exthome/jeff/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
ansible python module location = /usr/lib/python3.11/site-packages/ansible
ansible collection location = /exthome/jeff/.ansible/collections:/usr/share/ansible/collections
executable location = /usr/bin/ansible
python version = 3.11.5 (main, Sep 22 2023, 15:34:29) [GCC 8.5.0 20210514 (Red Hat 8.5.0-20)] (/usr/bin/python3.11)
jinja version = 3.1.2
libyaml = True
netaddr 1.0 (released 2024-02-10) removed the IPAddress.is_private() method. ansible.utils < 4.0 is only compatible with netaddr < 1.0; ansible.utils >= 4.0 is only compatible with netaddr >= 0.10.1.
Yep, I noticed this as well, so what is the solution we should recommend people? We can modify galaxy.yml to change the requirements
Not sure, the reason it breaks now is because the RPM version of netaddr in EPEL is 0.8.0, so unless you need something from the newer version of ansible.utils, it might be best to pin that to a lower version until EPEL catches up? But that's fully based on my gut feeling most people get netaddr from EPEL.
The other solution would be to recommend installing netaddr from PyPI, as the most recent release 'just works'
There's not really anything consumers of ansible.utils can do to resolve this, since it's a dependency between Ansible content and Python dependencies and there's no mechanism for handling those.
Ideally the maintainers would have maintained backwards compatibility with older versions of netaddr when they added support for 1.x. There's currently an open pull request that attempts to address this, though that does raise the issue that the way they reimplemented the filter for 1.x does not actually produce the same results in all cases as the old implementation.
Sorry, I went a little too abstract there and was speaking broadly about there being nothing you could change to help consumers of your content not run into this issue. For specific environments there are things that can be done to address this, e.g to fix CI we just need something like flowerysong@a846d02