Repository navigation
drift: check inventory at every release ref - #2693
Merged
Merged
Conversation
kolla_inventory compared upstream kolla-ansible's
ansible/inventory/multinode against generics/inventory/50-kolla and
51-kolla at a single ref -- sources.kolla_ansible.branch, stable/2025.2
by default. But osism/generics is single-tip: one inventory serves every
release OSISM builds, while upstream renames groups per release. So a
one-ref comparison can only ever vet one of the releases that inventory
has to satisfy, and it silently vets the wrong one as soon as the pin
lags the newest supported release.
2026.1 is where that bites. Upstream renamed kolla-toolbox ->
kolla_toolbox and kolla-logs -> kolla_logs, and added
cinder-{backup,volume}-{lvm,multiple},
prometheus-openstack-network-exporter and prometheus-valkey-exporter.
The OSISM inventory has none of those eight; the hyphenated spellings it
does have satisfy 2025.2, which is what the pin was pointing at. A group
a play selects on but no inventory defines is not an error -- the play
matches no hosts and deploys nothing, with no failed task -- so all
eight were invisible both to the detector and to a deploy.
Read multinode at every supported release's resolved ref instead
(release_range + release_to_ref, as the other range-aware plugins do)
and take the union: a group missing at ANY supported release is a
finding, because that one inventory must satisfy all of them at once. A
renamed group therefore needs both spellings for as long as both
releases are in range, which the remediation now says.
Findings stay keyed on the bare group name rather than on
group-and-release, so the fix stays "add it to the inventory once" and
the 15 shipped allowlist entries keep matching unchanged; the releases
that want the group ride in expected/expected_src instead, which also
groups the report by release. Members come from the last release in the
range order -- the newest, hence the spelling a maintainer is adding
for. An empty release range now raises rather than reporting clean,
matching kolla_enablement_orphan: with no release there is no multinode
to read and every missing group would go unreported.
Against the current checkouts this reports the eight 2026.1 groups
above. It also surfaces venus-{api,manager} at 2024.1 through 2025.1,
which OSISM does not deploy (enable_venus is "no", and the splitter
lists venus as an unsupported role), so those are allowlisted as
not-deployed alongside cyborg, tacker, telegraf and collectd -- which
un-stales the telegraf entry, dead while the check only looked at
2025.2.
The plugin's own test moves from reading the local multinode fixture to
mocking one per release ref, since per-ref reads cannot come from an
unpinned working tree. The fixture stays: it is what makes
FIXT/kolla-ansible a non-git dir for a pinned repo, the resolution path
the new config comment describes.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Roger Luethi <luethi@osism.tech>
Making the check range-aware made it read the release manifests, for the
supported release range, but left INPUT_FILES naming only kolla-ansible
and generics. The driver's pre-flight resolution keys off that list, so
a run whose --base-dir set lacks osism/release passes resolution --
which prints the repos it will use and hard-errors on a missing one --
and then dies mid-comparison on a repo it never announced it needed:
Resolving sources (1 base dir(s)):
generics local .../ws/generics
kolla_ansible local .../ws/kolla-ansible @ stable/2025.2
source error: repo 'release' not found under any --base-dir
Declare it, as kolla_enablement_build already does for the same read.
The resolution log then lists it, --help documents it, and a workspace
missing it fails before any comparison rather than partway through.
Found while wiring the check into a job outside this repo, where the
checkout layout decides whether osism/release is present at all.
Assisted-by: Claude:claude-opus-5
Signed-off-by: Roger Luethi <luethi@osism.tech>
ideaship
added a commit
to osism/generics
that referenced
this pull request
Sep 4, 2026
This repo has carried its own inventory-drift check since 2022, gated in CI since #602 (merged 2026-06-30). One day later osism/release landed kolla_inventory, a plugin in its check-drift tool that does the same comparison, and its docs described this script as retired -- which it was not. Two implementations of one check have run side by side ever since, and they had already diverged: this one compares against a single hardcoded KOLLA_BRANCH = "stable/2025.2", so it never saw that 2026.1 renames kolla-toolbox to kolla_toolbox and kolla-logs to kolla_logs and adds six more groups. The plugin, now range-aware, checks every release OSISM builds. Keep the gate, drop the duplicate implementation: tox -e check-kolla now invokes the plugin instead of the local script, and the job gains osism/release in required-projects so Zuul checks it out alongside this repo. The pipelines and the job name do not change. The gate is what makes this worth wiring rather than simply deleting. osism/release runs its detector in periodic-daily only, and reads this repo from GitHub main, so it can report drift a generics change introduced but never block it. Zuul checks out the proposed change here, so the plugin runs against the inventory under review -- and speculative merging means an in-flight change to the detector is tested against a real inventory before it lands. Nothing is suppressed that was suppressed before. IGNORE_ROLE_GROUPS and IGNORE_NOT_DEPLOYED are covered entry for entry by the plugin's shipped allowlist, including its own stale-entry guard; a local run reports 19 allowlisted and 0 stale. The detector needs only requests and PyYAML, both already pinned in this repo's requirements.txt at the same versions, so the tox env keeps its deps. The script's own guidance is not lost either: the plugin's remediation gives the same add-or-allowlist instruction, and names both spellings a renamed group needs while two releases want different ones. python3 ../release/src/check-drift.py --group kolla \ --plugin kolla_inventory --base-dir .. --remote-fallback \ --use-raw-get --base-dir .. finds this repo and osism/release as siblings, which is both the Zuul workspace layout and the usual one-directory-per-org local layout; kolla-ansible is not checked out, hence --remote-fallback. Each release contributes one file read, so --use-raw-get fetches those directly rather than a source tarball per ref. Verified locally: tox -e check-kolla passes against this branch, and fails with exit 1 against a main checkout that still lacks the 2026.1 groups. Depends-On: #616 Depends-On: osism/release#2693 Assisted-by: Claude:claude-opus-5 Signed-off-by: Roger Luethi <luethi@osism.tech>
ideaship
marked this pull request as ready for review
September 6, 2026 17:05
berendt
pushed a commit
to osism/generics
that referenced
this pull request
Sep 9, 2026
This repo has carried its own inventory-drift check since 2022, gated in CI since #602 (merged 2026-06-30). One day later osism/release landed kolla_inventory, a plugin in its check-drift tool that does the same comparison, and its docs described this script as retired -- which it was not. Two implementations of one check have run side by side ever since, and they had already diverged: this one compares against a single hardcoded KOLLA_BRANCH = "stable/2025.2", so it never saw that 2026.1 renames kolla-toolbox to kolla_toolbox and kolla-logs to kolla_logs and adds six more groups. The plugin, now range-aware, checks every release OSISM builds. Keep the gate, drop the duplicate implementation: tox -e check-kolla now invokes the plugin instead of the local script, and the job gains osism/release in required-projects so Zuul checks it out alongside this repo. The pipelines and the job name do not change. The gate is what makes this worth wiring rather than simply deleting. osism/release runs its detector in periodic-daily only, and reads this repo from GitHub main, so it can report drift a generics change introduced but never block it. Zuul checks out the proposed change here, so the plugin runs against the inventory under review -- and speculative merging means an in-flight change to the detector is tested against a real inventory before it lands. Nothing is suppressed that was suppressed before. IGNORE_ROLE_GROUPS and IGNORE_NOT_DEPLOYED are covered entry for entry by the plugin's shipped allowlist, including its own stale-entry guard; a local run reports 19 allowlisted and 0 stale. The detector needs only requests and PyYAML, both already pinned in this repo's requirements.txt at the same versions, so the tox env keeps its deps. The script's own guidance is not lost either: the plugin's remediation gives the same add-or-allowlist instruction, and names both spellings a renamed group needs while two releases want different ones. python3 ../release/src/check-drift.py --group kolla \ --plugin kolla_inventory --base-dir .. --remote-fallback \ --use-raw-get --base-dir .. finds this repo and osism/release as siblings, which is both the Zuul workspace layout and the usual one-directory-per-org local layout; kolla-ansible is not checked out, hence --remote-fallback. Each release contributes one file read, so --use-raw-get fetches those directly rather than a source tarball per ref. Verified locally: tox -e check-kolla passes against this branch, and fails with exit 1 against a main checkout that still lacks the 2026.1 groups. Depends-On: #616 Depends-On: osism/release#2693 Assisted-by: Claude:claude-opus-5 Signed-off-by: Roger Luethi <luethi@osism.tech>
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
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.
kolla_inventorycompared upstream kolla-ansible'sansible/inventory/multinodeagainst
generics/inventory/50-kolla+51-kollaat a single ref —sources.kolla_ansible.branch,stable/2025.2by default. Butosism/genericsis single-tip: one inventory serves every release OSISM builds, while upstream
renames groups per release. A one-ref comparison can only ever vet one of the
releases that inventory has to satisfy, and it vets the wrong one as soon as the
pin lags the newest supported release.
This reads multinode at every supported release's resolved ref
(
release_range+release_to_ref, as the other range-aware plugins do) andtakes the union: a group missing at any supported release is a finding, because
that one inventory must satisfy all of them at once.
Findings against
main(unfixed): 8 actionableAll eight are 2026.1.
kolla_logs/kolla_toolboxare a rename upstream(
kolla-logs/kolla-toolbox≤2025.2), which the OSISM inventory did notfollow, so those two 2026.1 plays select zero hosts and deploy nothing — silently,
with no failed task. The check pinned to
stable/2025.2could not see any of it.The fix for all eight:
With that applied the plugin reports
0 to act on, 0 advisory, 19 allowlisted, 0 stale entries.Also in this change
venusallowlisted. Looking at older releases surfacesvenus-{api,manager}at 2024.1–2025.1, which OSISM does not deploy(
enable_venus: "no", and the site.yml splitter lists venus unsupported), sothey join
cyborg/tacker/telegraf/collectdas not-deployed. Thisalso un-stales the
telegrafentry, which was dead while the check onlylooked at 2025.2.
fix stays "add it to the inventory once" and the 15 shipped allowlist entries
keep matching unchanged. The releases that want a group ride in
expected/expected_src, which also groups the report by release.the spelling a maintainer is adding for.
kolla_enablement_orphan: with no release there is no multinode to read andevery missing group would go unreported.
2026.1resolves tostable/2026.1, which upstream has already branched offmaster, so this compares against the ref the image actually builds from — not
against not-yet-released groups on master.
Test change
The plugin's own test moves from reading the local multinode fixture to mocking
one per release ref, since per-ref reads cannot come from an unpinned working
tree. New guard: local inventory holding
kolla-toolboxmust not hide upstream'skolla_toolboxat the newer release. 423 tests pass.Follow-up, not in this PR
osism/genericsstill ships its own single-branch copy of this check(
src/check-kolla-inventory.py,KOLLA_BRANCH = "stable/2025.2", wired asgenerics-tox-check-kollaincheck+ periodic). It merged 2026-06-30, one daybefore this plugin landed and claimed to subsume it, so the duplication is an
accident of sequencing. Retiring the generics implementation while keeping a
generics-side gate — a
checkjob withrequired-projects: [osism/release]running this plugin against the proposed inventory, which a periodic job in this
repo structurally cannot do — is in flight as:
That PR invokes this plugin, so merging it before this one means the gate checks
one release instead of five. It is not a hard dependency in the other direction. Note that
naively bumping the generics pin to
stable/2026.1instead would fail that joboutright:
telegrafis gone from multinode at 2026.1, so its stale-ignore guardexits 3.