Feature Overview (mandatory - Complete while in New status)
Support multi ceph clusters in a non DCN/DZ context.
We currently support multi ceph clusters but only in a DCN or DZ context.
Multi ceph clusters can be interesting for use cases outside DCN/DZ and we had multiple requests in the past. A 17.1 tripleo RFE was implemented but never officially tested.
Goals (mandatory - Complete while in New status)
Support deployments with multiple ceph clusters in a non DCN/DZ scenario.
In this scenario the computes are not grouped/isolated inside sites/AZs therefore all computes can consume the ceph clusters.
The main use case is for Cinder where a customer wants the option to define multiple cinder backends backed by ceph.
This can be for
- HCI + external
- One cluster is more performant than the other (tiering at the cluster level)
- HA - Deploy workloads across multiple ceph clusters to compensate the loss of one ceph cluster.
We should test with two clusters but the code/procedure should be flexible to add more. We can define a hard limit on the number of clusters.
Requirements (mandatory -_ Complete while in Refinement status):
A list of specific needs, capabilities, or objectives that a Feature must deliver to satisfy the Feature. Some requirements will be flagged as MVP. If an MVP gets shifted, the Feature shifts. If a non MVP requirement slips, it does not shift the feature.
Should be testonly from a core openstack pov. We already know how to define multi ceph cluster with RHOSO. We need to find/doc a way to distribute the ceph.conf & keys for each ceph cluster.
Configuring multiple cinder volume services each backing a ceph cluster already works with DCN/DZ.
Done - Acceptance Criteria (mandatory - Complete while in Refinement status):
Acceptance Criteria articulates and defines the value proposition - what is required to meet the goal and intent of this Feature. The Acceptance Criteria provides a detailed definition of scope and the expected outcomes - from a users point of view
…
<your text here>
Use Cases - i.e. User Experience & Workflow: (Initial completion while in Refinement status):
Include use case diagrams, main success scenarios, alternative flow scenarios.
<your text here>
Out of Scope __(Initial completion while in Refinement status):
High-level list of items or persona’s that are out of scope.
Glance and Nova - For now limit this to cinder
Documentation Considerations __(Initial completion while in Refinement status):
Provide information that needs to be considered and planned so that documentation will meet customer needs. If the feature extends existing functionality, provide a link to its current documentation..
<your text here>
Questions to Answer __(Initial completion while in Refinement status):
Include a list of refinement / architectural questions that may need to be answered before coding can begin.
How many clusters max?
Do we allow RHCS clusters that don't have the same major version?
Can we live migrate volumes between clusters? (should work but not tested)
Background and Strategic Fit (Initial completion while in Refinement status):
Provide any additional context is needed to frame the feature.
<your text here>
Customer Considerations __(Initial completion while in Refinement status):
Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.
<your text here>
Team Sign Off (Completion while in Planning status)
- All required Epics (known at the time) are linked to the this Feature
- All required Stories, Tasks (known at the time) for the most immediate Epics have been created and estimated
- Add - Reviewers name, Team Name
- Acceptance == Feature as “Ready” - well understood and scope is clear - Acceptance Criteria (scope) is elaborated, well defined, and understood
- Note: Only set FixVersion/s: on a Feature if the delivery team agrees they have the capacity and have committed that capability for that milestone
Reviewed By | Team Name | Accepted | Notes |
- …