[ideaship]

Option B of the consolidation: keep the gate, drop the duplicate implementation.

Why there are two

This repo has carried src/check-kolla-inventory.py 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 doing the same comparison —
and its docs described this script as "retired", which it was not. Both have run
side by side 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 → kolla_toolbox and kolla-logs → kolla_logs and adds
six more groups. The plugin, now range-aware, checks every release OSISM builds.

What changes

tox -e check-kolla invokes the plugin instead of the local script, and the job
gains osism/release in required-projects. Pipelines and the job name do not
change.

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 — 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. 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.

Why wire it rather than just delete the job

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. Speculative merging is a bonus in the other direction:
an in-flight change to the detector gets tested against a real inventory before it
lands.

Nothing is suppressed that was not suppressed before

IGNORE_ROLE_GROUPS and IGNORE_NOT_DEPLOYED are covered entry for entry by the
plugin's shipped allowlist, which has its own stale-entry guard. A local run
reports 19 allowlisted, 0 stale. The script's guidance is not lost either: the
plugin's remediation gives the same add-or-allowlist instruction, and additionally
names both spellings a renamed group needs while two supported releases want
different ones.

Verification

• tox -e check-kolla passes against this branch
• exit 1 against a main checkout that still lacks the 2026.1 groups, i.e. the
  gate still gates

Ordering — must not merge first

The new gate is red on main until the eight 2026.1 groups exist, so this carries
a Depends-On: for

• Add the kolla inventory groups 2026.1 introduced #616

Zuul speculatively merges that change into the workspace, so the gate job here runs
against the combined state and the dependency is enforced in the gate pipeline
rather than by a note. It also needs the range-aware detector it invokes:

• drift: check inventory at every release ref release#2693

#2693 is a Depends-On: too. It is not a hard merge dependency — the plugin
exists in osism/release main today, just single-ref — but without it in the
workspace the gate job proves nothing useful: the single-ref check at
stable/2025.2 is green whether or not the 2026.1 groups exist, so it cannot
distinguish a working gate from a no-op. The first run here did exactly that
(one read, multinode @ stable/2025.2, 16 allowlisted). With both dependencies
the job reads five refs and 19 allowlisted, which is a test that can fail.

Originally opened with #616 as its base branch. That gets no CI at all — Zuul
did not enqueue it, while two draft PRs based on main were enqueued the same
minute — so it is rebased onto main with Depends-On: instead. Worth knowing
for future stacked work in this tenant.

Not in this PR

osism/release docs still describe this script as retired; that sentence becomes
true when this merges. And note that the alternative once proposed for this repo —
bumping KOLLA_BRANCH to stable/2026.1 — would have failed the job outright
rather than reporting drift: telegraf is gone from multinode at 2026.1, so the
script's stale-ignore guard exits 3.