OSAC-2872: Storage Control Plane PRD - #134
openshift-merge-bot[bot] merged 8 commits into
Conversation
Product requirements for the OSAC Storage Control Plane: a CSI driver and control plane services that let CaaS tenants consume block storage through opaque tiers without vendor exposure, with per-request credential management, policy enforcement, and central volume inventory. v0.2 scope covers PV create, delete, and read with VAST as the only vendor backend. Volume attach/detach, resize, snapshots, and public volume API are out of scope. Signed-off-by: akshaynadkarni <25892229+akshaynadkarni@users.noreply.github.com> Assisted-by: Cursor/Claude Signed-off-by: akshaynadkarni <25892229+akshaynadkarni@users.noreply.github.com>
|
@akshaynadkarni: This pull request references OSAC-2872 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the feature to target the "5.0.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: akshaynadkarni The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Warning Review limit reached
Next review available in: 52 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Repository: osac-project/coderabbit/.coderabbit.yaml Review profile: ASSERTIVE Plan: Enterprise Run ID: 📒 Files selected for processing (1)
WalkthroughAdds a PRD for an OSAC Storage Control Plane, defining vendor-agnostic tiered storage, policy enforcement, credential handling, volume inventory, user workflows, scope boundaries, assumptions, and dependencies. ChangesStorage Control Plane Product Definition
Estimated code review effort: 1 (Trivial) | ~3 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 11✅ Passed checks (11 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
AI EP Review: EP-134Score: 9/10 | Verdict: PASS
Verdict: A well-structured PRD with clear user need, strong justification, and testable user stories, held back slightly by design leakage in the In Scope section where internal services and packaging are described alongside user-observable outcomes. Feedback: Rewrite In Scope items 2, 4, and 5 as user-observable outcomes rather than internal service descriptions. For example, replace 'Tier resolution (maps a tenant's StorageClass to the correct vendor backend)' with what the tenant or admin actually experiences. Remove the 'Private Volume API' item entirely — internal APIs belong in the design document, not the PRD. Consider adding a brief note about the Cloud Infrastructure Admin persona and whether their storage tier configuration workflows are covered by the OSAC-917 dependency. Critical (0)None. Important (3)
Suggestions (2)
Review costModel: claude-opus-4-6 |
…cket ID Signed-off-by: akshaynadkarni <25892229+akshaynadkarni@users.noreply.github.com> Assisted-by: Cursor/Claude Signed-off-by: akshaynadkarni <25892229+akshaynadkarni@users.noreply.github.com>
Remove volume attach/detach and PV update from out of scope since they were never in scope for this feature. Soften tenant inventory story to reflect that volume visibility through OSAC interfaces is OSAC-984 scope. Signed-off-by: akshaynadkarni <25892229+akshaynadkarni@users.noreply.github.com> Assisted-by: Cursor/Claude Signed-off-by: akshaynadkarni <25892229+akshaynadkarni@users.noreply.github.com>
AI EP Review: EP-134Score: 9/10 | Verdict: PASS
Verdict: A well-structured PRD with clear user outcomes and strong business justification, held back slightly by design leakage in In Scope items and a tenant inventory story that contradicts the private Volume API scope. Feedback: Rewrite In Scope items 2 and 4 to describe user-observable outcomes rather than internal architecture — e.g., replace 'Tier resolution (maps a tenant's StorageClass to the correct vendor backend)' with 'Tenants see only opaque storage tier names; vendor backend details are never exposed.' Resolve the contradiction between the Tenant User inventory story and the Private Volume API scope: either clarify how tenants observe volume tracking (e.g., via kubectl or a future public API) or remove the tenant-facing inventory story and keep it as a Cloud Provider Admin capability only. Consider adding Cloud Infrastructure Admin stories for storage backend and tier configuration, or explicitly note that persona's scope is covered by OSAC-917. Critical (0)None. Important (3)
Suggestions (3)
Review costModel: claude-opus-4-6 |
AI EP Review: EP-134Score: 8/10 | Verdict: PASS
Verdict: A solid PRD with clear user outcomes and strong justification, held back slightly by a missing Cloud Infrastructure Admin persona and design leakage in the In Scope section. Feedback: Add user stories for the Cloud Infrastructure Admin persona — they manage storage tiers and integrate with vendor backends like VAST per osac-dimensions.md, even if the configuration mechanism comes from OSAC-917, this PRD should describe what they observe and do. Rewrite In Scope items 2, 4, and 5 to describe user-observable outcomes rather than internal architecture (e.g., replace 'Private Volume API: Internal CRUD operations' with the admin-observable capability it enables). Add measurable targets to key user stories (e.g., 'storage ready within N minutes of cluster provisioning'). Critical (0)None. Important (3)
Suggestions (3)
Review costModel: claude-opus-4-6 |
Volume inventory tracks four states for v0.2: creating, available, deleting, deleted. Removed attached/detached states and VolumeAttachment API references since Kubernetes owns attachment lifecycle and those details belong in the design document, not the PRD. Signed-off-by: akshaynadkarni <25892229+akshaynadkarni@users.noreply.github.com> Assisted-by: Cursor/Claude Signed-off-by: akshaynadkarni <25892229+akshaynadkarni@users.noreply.github.com>
AI EP Review: EP-134Score: 8/10 | Verdict: PASS
Verdict: A solid PRD with clear user need, strong justification, and well-scoped capabilities, held back by a missing Cloud Infrastructure Admin persona and moderate design leakage in the In Scope section. Feedback: Add Cloud Infrastructure Admin user stories — this persona configures StorageBackend and StorageTier entities (OSAC-917), defines which vendor backends are available, and manages VAST integration. Without their stories, the PRD doesn't cover who sets up the storage infrastructure that tenants consume. Rewrite In Scope items 2, 4, 5, and 6 to describe user-observable outcomes rather than internal architecture: replace 'Private Volume API' with the admin capability it enables, replace 'tier resolution' with what the tenant sees, and replace 'storage driver packaging' with the deployment outcome. Consider adding Documentation and E2E Testing dimension coverage (even if deferred). Critical (0)None. Important (3)
Suggestions (3)
Review costModel: claude-opus-4-6 |
Separate the single volume inventory story into three persona-specific stories: Tenant User (attribution), Tenant Admin (org-wide visibility), Cloud Provider Admin (per-tenant accountability). Signed-off-by: akshaynadkarni <25892229+akshaynadkarni@users.noreply.github.com> Assisted-by: Cursor/Claude Signed-off-by: akshaynadkarni <25892229+akshaynadkarni@users.noreply.github.com>
AI EP Review: EP-134Score: 8/10 | Verdict: PASS
Verdict: A solid PRD with concrete justification and well-scoped capabilities, held back by a missing Cloud Infrastructure Admin persona and design leakage in the In Scope section. Feedback: Add Cloud Infrastructure Admin user stories for configuring storage backends, tiers, and monitoring storage health across tenants — this persona is central to the storage dimension per osac-dimensions.md. Rewrite In Scope items 2 and 4 to describe user-observable outcomes rather than internal mechanisms (e.g., replace 'Private Volume API: Internal CRUD operations' with the user-facing behavior it enables). Resolve the contradiction between user stories promising volume visibility to tenants and the Public Volume API being out of scope — either narrow those stories to what's observable via kubectl, or clarify what interface tenants will use. Critical (0)None. Important (4)
Suggestions (3)
Review costModel: claude-opus-4-6 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@enhancements/storage-control-plane-osac-2872/prd.md`:
- Around line 47-61: Clarify the Tenant Admin and Tenant User capability
definitions in the v0.2 storage requirements by specifying separate create,
delete, read, and list scopes. Tenant Users should be limited to their own
volumes and claims, while Tenant Admins should retain organization-wide
visibility across clusters; explicitly state the authorization scope for each
operation and remove the conflicting statement that both personas have identical
capabilities.
- Line 17: Clarify the v0.2 read scope in the “Storage driver for tenant
clusters” capability description: explicitly state whether PV/volume read
operations are supported through the control-plane driver or are limited to
native Kubernetes API visibility. Align this wording with the PR objective and
user story promising volume viewing, and apply the same clarification to the
corresponding repeated entry.
- Line 51: Clarify the PVC deletion behavior in the storage-control-plane
requirements: define the reclaim policy for generated StorageClasses so
successful PVC deletion removes the backing volume and releases storage, and
specify the inventory state transition and handling when volume deletion fails.
Update the tenant-admin/user deletion story or its acceptance criteria to
preserve these cleanup guarantees.
- Line 13: Clarify the credential trust boundary in the Storage Control Plane
description: ensure vendor plugins on tenant clusters never receive raw vendor
credentials, and specify that credentialed backend calls execute in the trusted
control plane or use an explicitly defined non-exposing flow.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 66b3d431-e42d-418a-9e5f-9f52066b94e7
📒 Files selected for processing (1)
enhancements/storage-control-plane-osac-2872/prd.md
|
|
||
| OSAC CaaS tenants need block storage on their clusters, but there is no vendor-agnostic storage layer today. Without one, tenants would see vendor-specific StorageClasses and backend addresses, vendor credentials would be stored on tenant clusters, there would be no enforcement point for per-tenant storage policy, and the platform would have no inventory of what volumes exist or which tenant owns them. | ||
|
|
||
| The Storage Control Plane introduces a single storage driver that presents opaque storage tiers to tenants, enforces authorization and tier-access policies, provides vendor credentials per-request without persisting them on tenant clusters, and tracks every volume in a central inventory. |
There was a problem hiding this comment.
we're not providing per-request credentials at the moment
|
|
||
| 1. **Storage driver for tenant clusters**: Handles PVC create, delete, and read (get/list) on tenant clusters through a standard Kubernetes PVC interface. StorageClasses are named after the tenant's configured storage tiers. v0.2 supports VAST as the only vendor backend for block storage. | ||
|
|
||
| 2. **Storage control plane services**: Tier resolution (maps a tenant's StorageClass to the correct vendor backend), policy enforcement (authorization and tier-access checks), and credential management (vendor credentials provided per-request, never stored on tenant clusters). |
There was a problem hiding this comment.
no per-request creds for now
|
|
||
| ## References | ||
|
|
||
| - [Architecture doc: OSAC CSI Meta-Driver](https://docs.google.com/document/d/1GCWco97kWNwFwfbC4TAoyXIxPSMO4CNyqFKv_lQczZU/edit?usp=sharing) |
There was a problem hiding this comment.
Those drive links are not available for people outside of RH org. we should probably think how to we share such docs, but for now I would remove those
|
nits mostly and quick fixes |
Remove per-request credential language since that model is not in scope for v0.2. Credential management is described as platform-managed and not visible to tenants, without prescribing the delivery mechanism. Remove References section with Google Docs links since they are not accessible outside Red Hat. Signed-off-by: akshaynadkarni <25892229+akshaynadkarni@users.noreply.github.com> Assisted-by: Cursor/Claude Signed-off-by: akshaynadkarni <25892229+akshaynadkarni@users.noreply.github.com>
AI EP Review: EP-134Score: 9/10 | Verdict: PASS
Verdict: A well-structured PRD with clear user stories and strong business justification, held back slightly by design leakage in the In Scope section and the absence of measurable acceptance criteria. Feedback: Rewrite In Scope items as user-observable outcomes rather than system components — e.g., replace 'Storage control plane services: Tier resolution (maps a tenant's StorageClass to the correct vendor backend)' with 'Tenants see only opaque storage tier names; the platform resolves tiers to backends without tenant involvement.' Add measurable acceptance criteria to key user stories (e.g., 'storage ready within 5 minutes of cluster provisioning') so QA can verify without reading code. Critical (0)None. Important (2)
Suggestions (2)
Review costModel: claude-opus-4-6 |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
enhancements/storage-control-plane-osac-2872/prd.md (1)
27-27: 🔒 Security & Privacy | 🟠 Major | ⚡ Quick winKeep vendor controllers off tenant clusters.
Line 27 says vendor plugins are deployed on tenant clusters, while the documented architecture places vendor CSI controllers on the hub/control plane. If interpreted literally, this conflicts with line 69’s guarantee that a compromised tenant cluster cannot access storage backends directly. Distinguish the tenant-facing driver and StorageClasses from hub-side vendor controllers and mediated backend calls.
Based on learnings, vendor CSI controllers run on the hub cluster and credentials never reach tenant clusters.
Also applies to: 69-69
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@enhancements/storage-control-plane-osac-2872/prd.md` at line 27, Update the automated cluster storage deployment statement to keep vendor CSI controllers and backend credentials on the hub/control plane, while deploying only the tenant-facing driver and tenant-specific StorageClasses to tenant clusters. Clarify that storage operations use mediated hub-side calls, preserving the line 69 guarantee that compromised tenant clusters cannot directly access storage backends.Source: Learnings
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@enhancements/storage-control-plane-osac-2872/prd.md`:
- Line 27: Update the automated cluster storage deployment statement to keep
vendor CSI controllers and backend credentials on the hub/control plane, while
deploying only the tenant-facing driver and tenant-specific StorageClasses to
tenant clusters. Clarify that storage operations use mediated hub-side calls,
preserving the line 69 guarantee that compromised tenant clusters cannot
directly access storage backends.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: fe90c428-1d11-4f57-984a-cdf6e20543c3
📒 Files selected for processing (1)
enhancements/storage-control-plane-osac-2872/prd.md
Signed-off-by: akshaynadkarni <25892229+akshaynadkarni@users.noreply.github.com> Assisted-by: Cursor/Claude Signed-off-by: akshaynadkarni <25892229+akshaynadkarni@users.noreply.github.com>
AI EP Review: EP-134Score: 9/10 | Verdict: PASS
Verdict: Strong PRD with clear user-facing need, concrete business justification, and well-scoped tightly-coupled capabilities; held back slightly by design leakage in the In Scope section where internal services and packaging details are described alongside user outcomes. Feedback: Rewrite In Scope items 2, 4, and 5 to describe user-observable outcomes rather than internal services — e.g., replace 'Tier resolution (maps a tenant's StorageClass to the correct vendor backend)' with 'Tenants see only opaque storage tier names; the platform resolves the correct backend transparently.' Remove or relocate the Private Volume API item to the design document since it is explicitly internal. Consider adding a note about the Cloud Infrastructure Admin persona — either add user stories for storage backend configuration or explicitly state that persona's needs are covered by the OSAC-917 dependency. Critical (0)None. Important (2)
Suggestions (3)
Review costModel: claude-opus-4-6 |
|
@coderabbitai review |
✅ Action performedReview finished.
|
|
@coderabbitai resolve |
✅ Action performedComments resolved and changes approved. |
|
/lgtm |
PRE_COMMIT_PR_BASE_SHA is a snapshot from the pull_request webhook payload, captured at the PR's last open/synchronize event. It doesn't advance as main gains new commits, and re-running an old CI job replays that same stale payload rather than refreshing it. This caused a false-positive class of failure: a long-lived PR that hasn't been pushed to since some other, unrelated PR merged a still-non-compliant enhancements/ directory into main would fail check-ep-naming on that unrelated directory, even though the PR never touches it and it's already correctly grandfathered on main itself. Observed concretely on PR #121, which failed on enhancements/storage-control-plane-osac-2872 (merged by PR #134) despite never touching that path. Fix: grandfathering now also checks the live tip of the base branch (PRE_COMMIT_LIVE_BASE_REF, e.g. origin/main, fetched fresh at the start of every CI run) in addition to the stale base SHA — a path is grandfathered if it exists at either reference. This keeps enforcement scoped to genuinely new paths, so contributors actively fixing their own directory's naming are never blocked by an unrelated pre-existing violation elsewhere in the repo. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Tommy Hughes <tohughes@redhat.com>
… main pass These 3 directories were missed by the original OSAC-2870 naming cleanup (osac-project#139/osac-project#144) specifically because they had active, unmerged PRs against them at the time the plan was drafted, so their Jira keys and directory names were still moving targets: - storage-control-plane-osac-2872 -> OSAC-2872-storage-control-plane (Jira key existed, but was still on an open PR (osac-project#134) that hadn't merged to main yet when osac-project#139 was planned/built) - cluster-and-vm-provisioning-wizard -> OSAC-1421-cluster-and-vm-provisioning-wizard (key OSAC-1421 has been in the doc's tracking-link since June; PR osac-project#108 was open against it at audit time) - metering-and-usage-tracking -> OSAC-985-metering-and-usage-tracking (key OSAC-985 has been in the doc's tracking-link for weeks; PRs osac-project#131 and osac-project#143 were open against it at audit time) Updated the one cross-reference found repo-wide pointing at the old cluster-and-vm-provisioning-wizard path (in OSAC-1319-bare-metal-instance-ui/design.md). No cross-references found for the other two. Note: PR osac-project#131 (open, adds a new metering-and-usage-tracking/design.md) will need to retarget to the new path when it rebases, since it adds a file git has no rename history for -- flagging this on that PR separately. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Tommy Hughes <tohughes@redhat.com>
PRE_COMMIT_PR_BASE_SHA is a snapshot from the pull_request webhook payload, captured at the PR's last open/synchronize event. It doesn't advance as main gains new commits, and re-running an old CI job replays that same stale payload rather than refreshing it. This caused a false-positive class of failure: a long-lived PR that hasn't been pushed to since some other, unrelated PR merged a still-non-compliant enhancements/ directory into main would fail check-ep-naming on that unrelated directory, even though the PR never touches it and it's already correctly grandfathered on main itself. Observed concretely on PR osac-project#121, which failed on enhancements/storage-control-plane-osac-2872 (merged by PR osac-project#134) despite never touching that path. Fix: grandfathering now also checks the live tip of the base branch (PRE_COMMIT_LIVE_BASE_REF, e.g. origin/main, fetched fresh at the start of every CI run) in addition to the stale base SHA — a path is grandfathered if it exists at either reference. This keeps enforcement scoped to genuinely new paths, so contributors actively fixing their own directory's naming are never blocked by an unrelated pre-existing violation elsewhere in the repo. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Tommy Hughes <tohughes@redhat.com>
… main pass These 3 directories were missed by the original OSAC-2870 naming cleanup (osac-project#139/osac-project#144) specifically because they had active, unmerged PRs against them at the time the plan was drafted, so their Jira keys and directory names were still moving targets: - storage-control-plane-osac-2872 -> OSAC-2872-storage-control-plane (Jira key existed, but was still on an open PR (osac-project#134) that hadn't merged to main yet when osac-project#139 was planned/built) - cluster-and-vm-provisioning-wizard -> OSAC-1421-cluster-and-vm-provisioning-wizard (key OSAC-1421 has been in the doc's tracking-link since June; PR osac-project#108 was open against it at audit time) - metering-and-usage-tracking -> OSAC-985-metering-and-usage-tracking (key OSAC-985 has been in the doc's tracking-link for weeks; PRs osac-project#131 and osac-project#143 were open against it at audit time) Updated the one cross-reference found repo-wide pointing at the old cluster-and-vm-provisioning-wizard path (in OSAC-1319-bare-metal-instance-ui/design.md). No cross-references found for the other two. Note: PR osac-project#131 (open, adds a new metering-and-usage-tracking/design.md) will need to retarget to the new path when it rebases, since it adds a file git has no rename history for -- flagging this on that PR separately. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Tommy Hughes <tohughes@redhat.com>
PRE_COMMIT_PR_BASE_SHA is a snapshot from the pull_request webhook payload, captured at the PR's last open/synchronize event. It doesn't advance as main gains new commits, and re-running an old CI job replays that same stale payload rather than refreshing it. This caused a false-positive class of failure: a long-lived PR that hasn't been pushed to since some other, unrelated PR merged a still-non-compliant enhancements/ directory into main would fail check-ep-naming on that unrelated directory, even though the PR never touches it and it's already correctly grandfathered on main itself. Observed concretely on PR osac-project#121, which failed on enhancements/storage-control-plane-osac-2872 (merged by PR osac-project#134) despite never touching that path. Fix: grandfathering now also checks the live tip of the base branch (PRE_COMMIT_LIVE_BASE_REF, e.g. origin/main, fetched fresh at the start of every CI run) in addition to the stale base SHA — a path is grandfathered if it exists at either reference. This keeps enforcement scoped to genuinely new paths, so contributors actively fixing their own directory's naming are never blocked by an unrelated pre-existing violation elsewhere in the repo. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Tommy Hughes <tohughes@redhat.com>
… main pass These 3 directories were missed by the original OSAC-2870 naming cleanup (osac-project#139/osac-project#144) specifically because they had active, unmerged PRs against them at the time the plan was drafted, so their Jira keys and directory names were still moving targets: - storage-control-plane-osac-2872 -> OSAC-2872-storage-control-plane (Jira key existed, but was still on an open PR (osac-project#134) that hadn't merged to main yet when osac-project#139 was planned/built) - cluster-and-vm-provisioning-wizard -> OSAC-1421-cluster-and-vm-provisioning-wizard (key OSAC-1421 has been in the doc's tracking-link since June; PR osac-project#108 was open against it at audit time) - metering-and-usage-tracking -> OSAC-985-metering-and-usage-tracking (key OSAC-985 has been in the doc's tracking-link for weeks; PRs osac-project#131 and osac-project#143 were open against it at audit time) Updated the one cross-reference found repo-wide pointing at the old cluster-and-vm-provisioning-wizard path (in OSAC-1319-bare-metal-instance-ui/design.md). No cross-references found for the other two. Note: PR osac-project#131 (open, adds a new metering-and-usage-tracking/design.md) will need to retarget to the new path when it rebases, since it adds a file git has no rename history for -- flagging this on that PR separately. Assisted-by: Claude Code <noreply@anthropic.com> Signed-off-by: Tommy Hughes <tohughes@redhat.com>
3 participants
Summary
Product requirements for OSAC-2872 (OSAC Storage Control Plane). Defines the storage architecture for CaaS tenant clusters: a CSI driver that presents opaque storage tiers, control plane services for tier resolution, policy enforcement, and credential management, volume inventory tracking, packaging, and automated deployment to tenant clusters.
Why
OSAC CaaS tenants need block storage but there is no vendor-agnostic storage layer today. Without one, tenants see vendor-specific StorageClasses and backend addresses, vendor credentials are stored on tenant clusters, there is no enforcement point for storage policy, and the platform has no inventory of volumes. This PRD captures the v0.2 scope and locked decisions from three rounds of clarification.
v0.2 Scope
Out of Scope (v0.2)
Dependencies
Ticket
OSAC-2872
Signed-off-by: akshaynadkarni 25892229+akshaynadkarni@users.noreply.github.com
Assisted-by: Cursor/Claude
Summary by CodeRabbit