placement — Change history

Change history — placement — branch stable/2026.2

Branch stable/2026.2 @ f4a89d3803cb — range 15.0.0..stable/2026.2 (97a81217ba4c..f4a89d3803cb, 15 non-merge commits) — no target project given — analysed on 2026-10-28

The range covers the whole 2026.2 cycle: everything merged on master after the 15.0.0 release (2026.1), up to the creation of stable/2026.2, plus the two commits made on the branch itself. The automatic range (since the branch left master) would only have contained those last two maintenance commits. Raw facts are in _inventory/history_stable-2026.2.md and .json. Commits are numbered in topological (application) order, which is not always chronological.

In short: the branch contains one functional fix (change 10, performance of GET /allocation_candidates) and two changes with an upgrade impact: Python ≥ 3.11 (change 4) and RBAC scope checks that can no longer be disabled (changes 5 and 6). The rest is dependencies, packaging and maintenance. There is no API change, new microversion, database migration, new error code or new configuration option in the range.

Summary

The other seven commits (1, 2, 3, 8, 13, 14, 15) are maintenance; see the table at the end.

4. Update python versions — upgrade

• Commit: 1c59ef1297ee — 2026-06-07 — review https://review.opendev.org/q/I9d61407180c8db04778bd3d3dd58df965a353257
• Before / after: Placement could be installed on Python 3.10. It now requires Python ≥ 3.11 (requires-python = ">=3.11", pyproject.toml:14), and declares 3.13 and 3.14 as supported classifiers. The CI jobs (.zuul.yaml, tox.ini) follow.
• Why: Python 3.10 left OpenStack's tested runtimes for 2026.2; 3.14 will be required later.
• Impact on the specification: none on the API or the data. Deployment requirement only.
• Upgrade / operations: a host still on Python 3.10 cannot install this version (pip refuses it because of requires-python). The release note (releasenotes/notes/drop-python-3-10-be063878f26fe3a7.yaml) says "supported by nova" instead of "Placement": a copy-paste slip in the note, with no effect on the code.
• Carrying it over: no prerequisite. Only the pyproject.toml and release-note parts matter to a fork; .zuul.yaml and tox.ini are OpenStack CI. Changes 12, 13 and 15 later touch the same files, so carry 4 before them.

5. Update policy scope enforcement testing — upgrade (reclassified)

• Commit: d1ad2c6e6b23 — 2026-05-06 — review https://review.opendev.org/q/Ia9c7530ffff6ea4c99dec73a1479e9ec079a1595 — Needed-By a Nova change and the oslo.policy change that removes enforce_scope.
• Category: the script classified it as "other". It is reclassified as upgrade, because it removes runtime code from placement/deploy.py and prepares the behaviour change of change 6.
• Before / after:
  • Before, when [oslo_policy] enforce_scope was False, deploy() silenced oslo.policy's "Policy … failed scope check" UserWarnings.
  • After, this filter is gone, and deploy() ends right after building the middleware pipeline (placement/deploy.py:45-119). The legacy-RBAC functional tests (placement/tests/functional/gabbits/*-legacy-rbac.yaml) and fixtures are rewritten to run with scope always enforced.
• Why: oslo.policy removes the deprecated enforce_scope option, so scope will always be enforced.
• Impact on the specification: no change to the routes or error codes by itself. It removes a startup behaviour (see 05).
• Upgrade / operations: with an oslo.policy that still has enforce_scope=False, scope-check warnings now appear in the logs instead of being silenced [inferred].
• Carrying it over: carry it together with change 6. Change 8 later modifies the same test fixture (placement/tests/functional/fixtures/placement.py). Most of the diff is tests.

6. Remove disabling the scope enforcement — upgrade

• Commit: 063aa00297fe — 2026-06-24 — review https://review.opendev.org/q/Ie291e9e7326ce7e61167acef1d0711a1c75cd454 — Depends-On the oslo.policy and releases changes for oslo.policy 6.0.0.
• Before / after:
  • Before, oslo.policy>=4.4.0: an operator could set [oslo_policy] enforce_scope = False to accept tokens whose scope does not match a policy's scope_types.
  • After, oslo.policy>=6.0.0 (requirements.txt:19): the option no longer exists, and scope checks are always enforced. Every Placement API rule declares scope_types=['project'] (placement/policies/base.py:45-71).
• Why: the end goal of OpenStack's "consistent and secure RBAC" community goal.
• Impact on the specification: 01 § Common mechanics (authorisation) and 02 § 403. A request whose token has the wrong scope now yields 403 whatever the configuration. In practice, this concerns a system-scoped token, given the project scope types [inferred].
• Upgrade / operations: the release note (releasenotes/notes/remove-disabling-rbac-scope-enforcement-4827620a50299038.yaml) states that nothing changes as long as oslo.policy stays below 6.0.0. A deployment that relied on enforce_scope = False must make sure its services (Nova, Neutron…) call Placement with project-scoped tokens before upgrading oslo.policy.
• Carrying it over: requires oslo.policy 6.0.0 in the target environment. Carry it after change 5. Changes 7 and 11 later touch requirements.txt.

7. Drop reference to lower-constraints.txt — dependencies

• Commit: a963581292a7 — 2026-06-29 — Trivial-Fix.
• Before / after: an obsolete comment in requirements.txt asked to keep lower-constraints.txt in sync for os-traits and os-resource-classes. That file was removed years ago, so the comment is removed. No effect on behaviour or on dependency versions.
• Carrying it over: optional, trivial. It touches requirements.txt after change 6.

10. Check overall capacity before generating candidates — fix

• Commit: 3457ecd69aa9 — 2026-07-16 — review https://review.opendev.org/q/I9bac03b0162009cdcea024f091bf63b177eaa279 — closes bug 2160721 — release note releasenotes/notes/bug-2160721-wide-symmetric-tree-performance-1c34375ee02a111c.yaml.
• Before: on wide, symmetric provider trees (for example 10 or more child providers of the same kind, such as mdev GPUs or PCI devices), GET /allocation_candidates could take an excessive time. This happened when a request asks for many granular groups of that resource (10 or more) and the tree has slightly fewer free devices than requested. The generation algorithm built a very large number of partial candidates before discovering that the last groups could not be satisfied.
• After: before generating the Cartesian product for a tree, Placement compares, for each resource class requested by more than one group, the total amount requested with the tree's total free capacity. It drops the tree straight away when the overall pool is not enough.
  • The pre-check is _pre_check_overall_capacity (placement/objects/allocation_candidate.py:794-844), applied as a filter in _get_areq_list_generators (placement/objects/allocation_candidate.py:747-791).
  • The totals are built while searching each group (placement/objects/allocation_candidate.py:151-155), in the new rcs_amounts counter (placement/objects/research_context.py:214).
  • It is a no-op when no class appears in several groups, or when there is a single group. The commit message reports that its cost is negligible in simple cases, so it is always on.
• Impact on the specification: 01 § Allocation candidates, algorithm step 3 (already updated). Results are unchanged: the candidates returned are the same, only faster in this edge case. No new error, option or microversion.
• Upgrade / operations: nothing to do. Deployments that had raised timeouts or set a low [placement]/max_allocation_candidates to work around the slowness may revisit those settings [inferred].
• Carrying it over:
  • Prerequisite: change 9 (f97c829ca0ab), the functional test that reproduces the bug. Change 10 modifies that test, so it does not apply cleanly without it.
  • Tests included: placement/tests/unit/objects/test_allocation_candidate.py (+67 lines) and placement/tests/functional/test_allocation_candidates.py.
  • Difficulty: moderate if the target's allocation_candidate.py has diverged. The diff rewrites _get_areq_list_generators (125 lines changed) and relies on rw_ctx.multi_group_rcs, so the target must already have the wide-tree optimisations that introduced it [inferred].

11. bump min version of os-traits — dependencies

• Commit: 7d35f974d52f — 2026-08-26 — review https://review.opendev.org/q/I0452e63bd08414579ba2bf97b8b0db510fe73f2a
• Before / after: os-traits>=3.3.0 becomes os-traits>=3.9.0 (requirements.txt:23), the latest release of the 2026.2 cycle. Every standard trait of that release is therefore available.
• Impact on the specification: the set of standard traits synced into the traits table at startup grows (05 § startup). Clients such as Nova can then use the new traits in required= filters.
• Carrying it over: requires os-traits 3.9.0 in the target environment. The new traits appear after the API processes restart.

12. [pyproject] Update setuptools config — dependencies (packaging)

• Commit: 01ac96d93374 — 2026-09-07 — review https://review.opendev.org/q/Icc6b40abcc455952694004585f053886eeb81005
• Before / after: pyproject.toml declared only the top-level placement package. It now uses [tool.setuptools.packages.find] with include = ["placement*"] (pyproject.toml:60-61), so that every sub-package is included in built distributions.
• Impact on the specification: none at run time when installed from a tree. It matters when building wheels or packages [inferred].
• Carrying it over: no prerequisite, apart from change 4 touching the same file earlier.

Maintenance-only changes

Carry-over plan

No target project was given, so presence in a target was not checked. The order below follows the branch history and puts prerequisites first. To check what your project already has, run:

python3 ~/.claude/skills/generate-reverse-spec/scripts/history.py placement --branch stable/2026.2 --since 15.0.0 \
    --target <your-repo> --target-branch <your-branch> --out reverse-spec-placement/_inventory

git cherry-pick -x 1c59ef1297ee1189de53bf3ac35177188722b58a   # upgrade: Python >= 3.11 (keep pyproject.toml and the release note)
git cherry-pick -x d1ad2c6e6b23c9b8694e85304457006ee00248ef   # upgrade: scope enforcement testing (needs oslo.policy 6.0.0)
git cherry-pick -x 063aa00297fed3d8bc80bec95e4db6f73673c1f4   # upgrade: oslo.policy >= 6.0.0, scope always enforced
git cherry-pick -x a963581292a734f6b1596ace9ea5cff42b4d621f   # dependencies: obsolete comment (optional)
git cherry-pick -x f97c829ca0ab9106e44070045ea0ba9b37f78eff   # test reproducing bug 2160721 (prerequisite of the fix)
git cherry-pick -x 3457ecd69aa966c9f278c8bf7b2a90a5d9f96a3a   # fix: bug 2160721, candidate generation on wide trees
git cherry-pick -x 7d35f974d52fdbb457ff2b6b7bff3741165dd30d   # dependencies: os-traits >= 3.9.0
git cherry-pick -x 01ac96d93374a8e2e8c9a1b650fb009085caeb39   # packaging: include all placement* packages

To carry only the functional fix, apply the test and the fix: f97c829ca0ab, then 3457ecd69aa9.

Source: reverse-spec-placement/06-change-history_stable-2026.2.md. The _rewrite/ and _inventory/ files are not published on the site.