-
Epic
-
Resolution: Unresolved
-
Undefined
-
rhos-18.0.17 FR 5
-
None
-
Document Single keystone Multiple OpenStack (SKMO)
-
S
-
False
-
-
False
-
-
Not Selected
-
Proposed
-
Proposed
-
To Do
-
RHOSSTRAT-907 - Single keystone Multiple OpenStack (SKMO) - test upgrades
-
Proposed
-
rhos-ops-platform-services-security
-
Proposed
-
50% To Do, 50% In Progress, 0% Done
-
-
-
Goal:
As part of the new Jobs to be Done (JTBD) framework adopted by CCS, this must express the JOB that the customer needs to accomplish because of this Engineering epic.
In other words, I need to answer the WHY associated with this job of work first.
Then I need to answer the WHAT and HOW questions, for example: As a <User/Actor>, I Want <to Achieve Some Goal>, so that <Some Reason/Context>.
As an OpenStack admin, I want to simplify the user management of multi-region deployments, so that end users can access any region using a single set of credentials. And to further simplify the user management by providing one region in which to enable or disable access.
In more detail:
Single Keystone Multiple OpenStacks (SKMO) simplifies the user management of multi-region deployments, by centralizing both the Dashboard (horizon) and Identity (keystone) services in regionOne.
Previous multi-region setups were isolated OpenStack deployments, each with its own Dashboard (horizon) and Identity (keystone) services. Therefore, if a user requires access to multiple regions, then you must create a user account for the same user in each region and then separately manage these multiple sets of credentials.
SKMO allows end users to access any workload region with a single set of credentials and further simplifies user management by providing a single region, regionOne, to enable or disable access.
While regionOne is deployed normally, each of the deployed workload regions require a modified deployment, to configure them to use the shared Dashboard (horizon) and Identity (keystone) services of regionOne.
Note: Currently SKMO results in reduced security, because the traffic that would have been on private networks for each of the workload regions must be added to the public network of regionOne.
The modified deployment requires the following manual configuration:
Get this from this meeting recording:
Discuss SKMO documentation for FR5 - 2026/02/09 14:56 GMT - Notes by Gemini
Acceptance Criteria:
- Documentation accepted by the Security DFG
Mini content journey:
This must be completed as part of the refinement process
Reviewers:
- Technical: Ade / Doug
- Peer: Rodger
- QE: Veronika
What stage of the user journey are you targeting?
- Adopt: NOT Adoption but Greenfield __ feature ONLY
NOT: Expand: Customizations, day 2 operations, troubleshooting, add features to control plane or data plane
Who is your target persona?
- OpenStack admin: Cloud Administrator
What type of information does the user need to know in order to use the feature?
- Procedures to implement or enable the feature
- Procedures to verify that the feature is enabled and is working as expected
- Concepts that need to be explained or planning decisions that must be made before the user can perform any of these procedures
Does the content need to be included in any of the following guides?
- Planning guide: Are there prerequisites or planning decisions to add to the Planning guide?
- Deployment/Customization guide: Does the feature need to be enabled during the deployment process, or can it be enabled post-deployment?