ansible-build-data
ansible-build-data copied to clipboard
ansible-community
Ansible 10.0 release throws SynaxError while gathering fact
13:54:14 File "<stdin>", line 7
13:54:14 SyntaxError: future feature annotations is not defined
13:54:14 debug3: mux_client_read_packet: read header failed: Broken pipe
13:54:14 debug2: Received exit status from master 1
13:54:14 canceled
13:54:14 script returned exit code 130
Our pipelines got an upgrade from 9.6.0 to 10.0 today and hit a network timeout gathering facts. Executing with -vvv gave us the above error. We have rollbacked to 9.6.0 as a temporary work around.
What is the target node running? Note that ansible-core 2.17 that's included in ansible 10 no longer supports targets with Python 2.7 or Python 3.6 (this includes RHEL 7 and 8). Still, Core should probably provide a proper error message that the Python version is unsupported instead of failing with syntax errors.
This is executing in the centos:stream8 docker container.
Target nodes are...
Red Hat Enterprise Linux release 8.8 (Ootpa)
python3 --version Python 3.6.8
Well, Python 3.6 is no longer supported on the target nodes, see the changelog (https://github.com/ansible-community/ansible-build-data/blob/main/10/CHANGELOG-v10.md#ansible-core-5) or the porting guide (https://docs.ansible.com/ansible/devel/porting_guides/porting_guide_10.html#command-line).
You either need to install a newer Python version on the remotes (if you need to do that in a playbook, first disable fact gathering, then use the ansible.builtin.raw module to install a newer Python than 3.6, and then run fact gathering explicitly), or alternatively (and also unfortunately) stick to Ansible 9.
(TBH I'm not sure how you can use the dnf/yum modules on RHEL 8 with ansible-core 2.17, since I guess the spawning feature also won't work with Python 3.6 anymore.)
I think the best option for those sticking with Alma/Rocky/RHEL/Stream 8 is to lock in 9.x, or switch to installing ansible-core locked at 2.16.x and install all the collections you need separately.
That's my plan for my Rocky Linux 8 test container, at least. https://github.com/geerlingguy/docker-rockylinux8-ansible/issues/6#issuecomment-2154308673
You won't get the same kind of 'LTS-style' coverage locking in pip install 'ansible<10.0' that you would with the pip install ansible-core<2.17
Note that 9.x.y is currently a "kind of" LTS version, releases for it are published for another half a year until Ansible 11 comes out. This was originally mainly done for Python 2.7 compatibility, but I guess it's also relevant for Python 3.6 :)
Unfortunately that means no major collection bumps, which means no new features in some collections (and no new releases at all for others). (That's also why it's not really LTS.)
Note that 9.x.y is currently a "kind of" LTS version, releases for it are published for another half a year until Ansible 11 comes out. This was originally mainly done for Python 2.7 compatibility, but I guess it's also relevant for Python 3.6 :)
Unfortunately that means no major collection bumps, which means no new features in some collections (and no new releases at all for others). (That's also why it's not really LTS.)
Presuming the reference for 9.x was the Enterprise Linux Major.Minor version I would say this isn't quite accurate, but I could be misinterpreting your statement. I would say RHEL 9.x is an LTS version, but it's not currently past the Full Support Phase where SW version changes or enhancements might occur. RHELs current lifecycle (for 8 and 9) Full Support lasts 5 years now (Red Hat Enterprise Linux Life Cycle), but from what I recall enhancement phases did not last 5 years in prior releases. This might be what you are referencing in your timeline. May 17th 2022 was the RHEL 9.x official release, so 5 years of Full Support means enhancements could occur up to May 2027, where another 1/2 year would only be to around 2.5 years into Full Support.
Although, if Fedora didn't already integrate one of those newer versions the chance it gets added to CentOS Stream 9 and eventually RHEL 9.x before the Maintenance Support phase begins seems fairly unlikely.
No, my 9.x.y reference was to Ansible 9.x.y. That one has new releases for a year, as opposed to half a year as for other Ansible major release trains.