-
Feature
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
None
-
None
-
Not Selected
-
False
-
False
-
-
-
0
-
0
-
0% To Do, 100% In Progress, 0% Done
-
Red Hat OpenStack Services on OpenShift (formerly Red Hat OpenStack Platform)
Feature Overview
Export location metadata in OpenStack Manila is a feature that aids end users identify export paths with configurable key=value pairs that are programmatically retrievable and editable.
This feature could enable an automated and auditable workflow for compliance. An administrator can add a key-value pair like location: germany-west to a share's metadata. This metadata can then be queried programmatically to verify that shares are correctly located. This eliminates the need for manual tracking and allows for the development of automated scripts to periodically audit and flag any shares that are out of compliance, providing a reliable and efficient way to manage and prove adherence to data residency laws.
Share back end drivers also create metadata that's useful in the same regard. This metadata would not be appropriate for end users to edit/delete.
Goals
This feature must benefit:
- End users that create/manage their own shares can benefit from adding custom metadata that their applications can parse
- Manila CSI driver - an integration in OpenShift which can automatically parse metadata from export paths and act on these as instructions while mounting shares to pods.
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.
| Requirement | Notes | isMVP? |
|---|---|---|
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.
<your text here>
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.
<your text here>
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 |
- …