Cap openstacksdk <4.11 to fix openstack.cloud collection break#2501
Closed
ideaship wants to merge 1 commit into
Closed
Cap openstacksdk <4.11 to fix openstack.cloud collection break#2501ideaship wants to merge 1 commit into
ideaship wants to merge 1 commit into
Conversation
openstacksdk 4.17.0 (merged via #2292 on 2026-07-20) is incompatible with the galaxy-pinned openstack.cloud 2.5.0 ansible collection: its openstack_cloud_from_module helper references openstack.version, which the newer sdk no longer exposes. Every openstack.cloud module in the osism-ansible manager container then fails with "module 'openstack' has no attribute 'version'", which broke all testbed periodic-midnight jobs on 2026-07-22 (they passed the night before). The sdk is pinned in two files that separate Renovate managers keep in sync: requirements.txt (the pip_requirements manager; also the wheel's install_requires via setup.cfg) and Pipfile/Pipfile.lock (the pipenv manager). Revert both to the proven-good set for collection 2.5.0: openstacksdk 4.10.0 and python-openstackclient 9.0.0. openstackclient 10.x requires openstacksdk >=4.16, so it must move together with the sdk. Regenerating Pipfile.lock also re-added requestsexceptions (needed by the 4.10.0 tree) and refreshed two unrelated transitive deps (certifi, platformdirs). Add Renovate allowedVersions caps (openstacksdk <4.11, python-openstackclient <10) covering all managers so neither requirements.txt nor the Pipfile can silently drift past the collection compatibility boundary again. Raise the caps only together with an openstack.cloud bump in osism/release. Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Roger Luethi <luethi@osism.tech>
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Member
|
Not required. Bump of the OpenStack collection was sufficient. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
openstacksdk
4.17.0is incompatible with the galaxy-pinnedopenstack.cloud2.5.0ansible collection. The collection's sharedopenstack_cloud_from_modulehelper referencesopenstack.version, which thenewer sdk no longer exposes, so every
openstack.cloudmodule in theosism-ansible manager container fails with:
This broke all testbed
periodic-midnightjobs on 2026-07-22 (they passedthe night before). The sdk bump rode in via:
Change
Revert to the proven-good set that matches collection
2.5.0, and cap it so itcannot silently drift again:
requirements.txt+Pipfile+Pipfile.lock:openstacksdk4.17.0→4.10.0,python-openstackclient10.2.1→9.0.0(openstackclient 10.x requiresopenstacksdk
>=4.16, so the two must move together)..github/renovate.json:allowedVersionscaps (openstacksdk <4.11,python-openstackclient <10) covering all managers, so neitherrequirements.txt(pip_requirements) nor thePipfile(pipenv) can outrun thecollection again.
Pipfile.lockwas regenerated withpipenv lock(re-addsrequestsexceptionsfor the 4.10.0 tree; incidentally refreshes
certifiandplatformdirs).Follow-up
The caps are the compatibility contract: raise them only together with an
openstack.cloudbump inosism/release. Longer term, the sdk is pinnedredundantly in both
requirements.txtand thePipfile(two Renovate managers,no generation link) — that duplication should be single-sourced.
🤖 Generated with Claude Code