Category: feature | Scope: Small
Blocked on k-orc/openstack-resource-controller#862 — the K-ORC Region controller this issue builds on is still an open PR; the K-ORC main pseudo-version pin can only move onto a commit containing it once that PR merges.
Description
A ControlPlane places its entire identity catalog in a single Keystone region, named by spec.region and defaulting to RegionOne. Today that region exists only as a side effect: keystone-manage bootstrap creates it while seeding the initial admin identity, and no declarative object represents it afterwards. It cannot carry a description, does not appear among the cluster's K-ORC resources, and sits outside the ownership model that expresses every other identity resource — domains, projects, users, services, endpoints — as a K-ORC custom resource.
K-ORC now ships a Region controller (k-orc/openstack-resource-controller#862): a Region resource whose immutable name is the Keystone region ID, plus a mutable description, with support for both creating a region and adopting one that already exists.
This issue brings the bootstrap region under that model. After Keystone bootstrap, the operator adopts the region named by spec.region as a managed K-ORC Region resource. The region then appears alongside the other catalog resources, its description is maintained declaratively, and its lifecycle follows the ControlPlane like every other managed identity resource. One region per ControlPlane remains the model; the work adds no multi-region support. The scope is the bootstrap path only, so a ControlPlane running against an external Keystone is untouched.
Two constraints hold, per the author:
- No K-ORC release ships the Region controller yet, so the work assumes forge pins a K-ORC main pseudo-version, as it already does for role assignments.
- Placing the catalog's service endpoints into the ControlPlane's region stays out of scope: K-ORC's Endpoint resource cannot reference a region, so endpoints created through K-ORC keep an empty region until K-ORC grows that capability. That gap is pursued upstream, separately.
Motivation
Whoever operates a ControlPlane reads its identity state from K-ORC custom resources, and the region is the piece missing from that picture. It exists in Keystone, is named in every generated clouds.yaml, and anchors the bootstrap endpoints, yet nothing in the cluster represents or owns it — and a description, the one attribute a Keystone region carries, cannot be set at all.
Adopting the region closes that gap for platform operators auditing a deployment through its custom resources, and it keeps the project's own rule intact: every identity resource a ControlPlane depends on is a declarative, operator-owned object. Any later multi-region work then starts from a region that is already a first-class object rather than a bootstrap side effect.
Drafted by planwerk-agent with Claude:claude-fable-5
Category: feature | Scope: Small
Blocked on k-orc/openstack-resource-controller#862 — the K-ORC Region controller this issue builds on is still an open PR; the K-ORC main pseudo-version pin can only move onto a commit containing it once that PR merges.
Description
A ControlPlane places its entire identity catalog in a single Keystone region, named by
spec.regionand defaulting toRegionOne. Today that region exists only as a side effect:keystone-manage bootstrapcreates it while seeding the initial admin identity, and no declarative object represents it afterwards. It cannot carry a description, does not appear among the cluster's K-ORC resources, and sits outside the ownership model that expresses every other identity resource — domains, projects, users, services, endpoints — as a K-ORC custom resource.K-ORC now ships a Region controller (k-orc/openstack-resource-controller#862): a Region resource whose immutable name is the Keystone region ID, plus a mutable description, with support for both creating a region and adopting one that already exists.
This issue brings the bootstrap region under that model. After Keystone bootstrap, the operator adopts the region named by
spec.regionas a managed K-ORC Region resource. The region then appears alongside the other catalog resources, its description is maintained declaratively, and its lifecycle follows the ControlPlane like every other managed identity resource. One region per ControlPlane remains the model; the work adds no multi-region support. The scope is the bootstrap path only, so a ControlPlane running against an external Keystone is untouched.Two constraints hold, per the author:
Motivation
Whoever operates a ControlPlane reads its identity state from K-ORC custom resources, and the region is the piece missing from that picture. It exists in Keystone, is named in every generated clouds.yaml, and anchors the bootstrap endpoints, yet nothing in the cluster represents or owns it — and a description, the one attribute a Keystone region carries, cannot be set at all.
Adopting the region closes that gap for platform operators auditing a deployment through its custom resources, and it keeps the project's own rule intact: every identity resource a ControlPlane depends on is a declarative, operator-owned object. Any later multi-region work then starts from a region that is already a first-class object rather than a bootstrap side effect.
Drafted by planwerk-agent with Claude:claude-fable-5