Skip to content

.zuul: update ansible-version to v11#1824

Merged
debarshiray merged 1 commit into
containers:mainfrom
TristanCacqueray:bump-ansible
Jul 24, 2026
Merged

.zuul: update ansible-version to v11#1824
debarshiray merged 1 commit into
containers:mainfrom
TristanCacqueray:bump-ansible

Conversation

@TristanCacqueray

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates the .zuul.yaml configuration to set ansible-version: 11 for a system test job. The review feedback points out that other jobs running on Fedora Rawhide should also be updated to use ansible-version: 11 to avoid Python 3.13 compatibility issues.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

Comment thread .zuul.yaml Outdated
@centosinfra-prod-github-app

Copy link
Copy Markdown

Merge Failed.

This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.
Warning:
Unable to update github.com/containers/toolbox

@centosinfra-prod-github-app

Copy link
Copy Markdown

Merge Failed.

This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset.
Warning:
Unable to update github.com/containers/toolbox

@TristanCacqueray

Copy link
Copy Markdown
Contributor Author

recheck github blip

@TristanCacqueray

Copy link
Copy Markdown
Contributor Author

recheck # Failed to cache image quay.io/toolbx/ubuntu-toolbox:20.04 to /var/tmp/bats-run-G8bcNa/suite/image-cache/ubuntu-toolbox-20.04

@centosinfra-prod-github-app

Copy link
Copy Markdown

@debarshiray debarshiray left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for fixing and investigating this, @TristanCacqueray ! I am curious how ansible-version: 11 maps to ansible-core 2.18 so that I can handle similar issues myself without bothering you. :)

I found the documentation of a Zuul job, which mentions ansible-version. It says that 9 is the default and the other option is 11, and it doesn't say anything about the mapping. I found a few other pieces of documentation with similar results.

I tracked it down to the JobParser.fromYaml() method in Zuul's zuul/configloader.py, but I still can't find a mapping to the ansible-core version.

@debarshiray

debarshiray commented Jul 23, 2026

Copy link
Copy Markdown
Member

Thanks for fixing and investigating this, @TristanCacqueray ! I am curious how ansible-version: 11 maps to Ansible-core 2.18 so that I can handle similar issues myself without bothering you. :)

Oops! Just after submitting the review, I managed to coax Google/Gemini to teach me that the Ansible (community?) package version and the ansible-core version are different things. After some digging around, I found the Ansible 11 release notes, and the specific notes for v11.0.0 says:

Ansible 11.0.0 contains ansible-core version 2.18.0. This is a newer version than version 2.17.0 contained in the previous Ansible release.

I guess I answered my own question. :)

@gemini-code-assist

Copy link
Copy Markdown

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

@debarshiray debarshiray left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While fiddling around with Ansible, I realized that I already have Python 3.13 on my old stable Fedora host, which got me curious about what's going on in Fedora Rawhide. :)

Some Git forensics brought me to this CPython commit for Python 3.15 about adding support for OpenSSL 4.0. A quick read of the commit was puzzling because this worked with all three of Fedora's python3.13, python3.14 and python3.15 packages on my old Fedora:

>>> import ssl
>>> ssl.PROTOCOL_TLSv1

Some head scratching later, I read the commit again and realized that only the use of OpenSSL 4.0, which I don't have on my host, removes ssl.PROTOCOL_TLSv1. This was reported downstream in Fedora, and is being tracked upstream at python/cpython#152709 and should be addressed by python/cpython#152714

This only affects Fedora Rawhide because of the Python3.15 and OpenSSL40 Changes.

debarshiray pushed a commit to TristanCacqueray/toolbox that referenced this pull request Jul 23, 2026
The default Python stack in Fedora Rawhide was updated from version 3.14
to 3.15 [1], and OpenSSL 4.0 was introduced [2].  As a result of this
combination, the PROTOCOL_TLSv1 attribute disappeared from Python's ssl
module [3].  This prevents Zuul from working with Fedora Rawhide hosts,
because of this Ansible error:
  TASK [add-build-sshkey : Enable access via build key on all nodes] ***
  An exception occurred during task execution. To see the full
      traceback, use -vvv.
  The error was: AttributeError: module 'ssl' has no attribute
      'PROTOCOL_TLSv1'. Did you mean '.PROTOCOL_TLS' instead of
      '.PROTOCOL_TLSv1'?

The use of ssl.PROTOCOL_TLSv1 was removed from ansible-core 2.17.0 [4],
which became available in Ansible 10 [5]; and since Zuul 13.0.0, the
default Ansible version is 9, and version 11 can be optionally used.

Therefore, explicitly selecting Ansible 11 resolves this breakage when
the combination of Python 3.15 and OpenSSL 4.0 are used.

[1] https://fedoraproject.org/wiki/Changes/Python3.15

[2] https://fedoraproject.org/wiki/Changes/OpenSSL40

[3] CPython commit 3364e7e62fa24d0e
    python/cpython@3364e7e62fa24d0e
    python/cpython#146217
    python/cpython#146207

[4] ansible-core commit 92d2c66db2eecd0f
    ansible/ansible@92d2c66db2eecd0f
    ansible/ansible#81880

[5] https://github.com/ansible-community/ansible-build-data/blob/main/10/CHANGELOG-v10.md

[6] https://zuul-ci.org/docs/zuul/latest/releasenotes.html

containers#1824

Signed-off-by: Tristan Cacqueray <tdecacqu@redhat.com>
@debarshiray

Copy link
Copy Markdown
Member

I took the liberty to update the Git commit message with a summary of my ramblings as a crutch for future forgetful me. :)

Let's merge once the CI passes. In the meantime, I will go out for a walk.

@TristanCacqueray

Copy link
Copy Markdown
Contributor Author

@debarshiray haa good catch, thank you for the details!

For the version mapping, I used the wrong link in the commit message, I had too many tabs and I meant to paste: https://docs.ansible.com/projects/ansible/latest/reference_appendices/release_and_maintenance.html#ansible-community-changelogs <- this shows the mapping between ansible and ansible-core.

@TristanCacqueray

Copy link
Copy Markdown
Contributor Author

recheck failed to load images when context deadline exceeded

The default Python stack in Fedora Rawhide was updated from version 3.14
to 3.15 [1], and OpenSSL 4.0 was introduced [2].  As a result of this
combination, the PROTOCOL_TLSv1 attribute disappeared from Python's ssl
module [3].  This prevents Zuul from working with Fedora Rawhide hosts,
because of this Ansible error:
  TASK [add-build-sshkey : Enable access via build key on all nodes] ***
  An exception occurred during task execution. To see the full
      traceback, use -vvv.
  The error was: AttributeError: module 'ssl' has no attribute
      'PROTOCOL_TLSv1'. Did you mean '.PROTOCOL_TLS' instead of
      '.PROTOCOL_TLSv1'?

The use of ssl.PROTOCOL_TLSv1 was removed from ansible-core 2.17.0 [4],
which became available in Ansible 10 [5,6]; and since Zuul 13.0.0, the
default Ansible version is 9, and version 11 can be optionally used [7].

Therefore, explicitly selecting Ansible 11 resolves this breakage when
the combination of Python 3.15 and OpenSSL 4.0 are used.

[1] https://fedoraproject.org/wiki/Changes/Python3.15

[2] https://fedoraproject.org/wiki/Changes/OpenSSL40

[3] CPython commit 3364e7e62fa24d0e
    python/cpython@3364e7e62fa24d0e
    python/cpython#146217
    python/cpython#146207

[4] ansible-core commit 92d2c66db2eecd0f
    ansible/ansible@92d2c66db2eecd0f
    ansible/ansible#81880

[5] https://docs.ansible.com/projects/ansible/latest/reference_appendices/release_and_maintenance.html

[6] https://github.com/ansible-community/ansible-build-data/blob/main/10/CHANGELOG-v10.md

[7] https://zuul-ci.org/docs/zuul/latest/releasenotes.html

containers#1824

Signed-off-by: Tristan Cacqueray <tdecacqu@redhat.com>
@debarshiray

Copy link
Copy Markdown
Member

For the version mapping, I used the wrong link in the commit message, I had too many tabs and I meant to paste: https://docs.ansible.com/projects/ansible/latest/reference_appendices/release_and_maintenance.html#ansible-community-changelogs <- this shows the mapping between ansible and ansible-core.

I see, cool. I included it in the commit message.

@debarshiray
debarshiray merged commit 93f882c into containers:main Jul 24, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants