Skip to content

OSAC-1110: storage UI design doc follow-ups (post-#183) #187

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
openshift-merge-bot merged 2 commits into from
Aug 5, 2026
Merged

OSAC-1110: storage UI design doc follow-ups (post-#183) #187

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1d67751
OSAC-1110: tighten Motivation to state rationale, not revision history
ElayAharoni Aug 5, 2026
34c1bae
OSAC-1110: cite the OSAC-1111 PRD alongside OSAC-1110's
ElayAharoni Aug 5, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 5 additions & 4 deletions enhancements/OSAC-1110-storage-tier/ui-design.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,7 @@ tracking-link:
- https://redhat.atlassian.net/browse/OSAC-1111
prd:
- "prd.md"
- "../OSAC-1111-storage-backend/prd.md"
see-also:
- "/enhancements/OSAC-1111-storage-backend"
- "/enhancements/OSAC-2872-storage-control-plane"
Expand All @@ -21,15 +22,15 @@ superseded-by:

## Summary

This design specifies the `osac-ui` implementation for both `StorageBackend` (OSAC-1111) and `StorageTier` (OSAC-1110) admin management: a combined "Storage" admin section, with a Backends tab and a Tiers tab, where Cloud Provider Admins register storage infrastructure and compose named tier offerings (e.g., "fast", "standard") on top of it. See [PRD](prd.md) for detailed requirements and [design.md](design.md) for the `StorageTier` API contract this UI consumes.
This design specifies the `osac-ui` implementation for both `StorageBackend` (OSAC-1111) and `StorageTier` (OSAC-1110) admin management: a combined "Storage" admin section, with a Backends tab and a Tiers tab, where Cloud Provider Admins register storage infrastructure and compose named tier offerings (e.g., "fast", "standard") on top of it. See the [StorageTier PRD](prd.md) and [StorageBackend PRD](../OSAC-1111-storage-backend/prd.md) for detailed requirements, and [design.md](design.md) / [../OSAC-1111-storage-backend/design.md](../OSAC-1111-storage-backend/design.md) for the API contracts this UI consumes.

## Motivation

OSAC has no API-managed inventory of storage infrastructure or tier offerings today: backend configuration lives in Ansible extra vars, and tier configuration lives in the `STORAGE_TIERS` environment variable plus Kubernetes label conventions — both invisible to the OSAC API and to any UI. `StorageBackend` and `StorageTier` replace these with DB-backed private gRPC resources. `osac-ui` is the only *graphical* interface Cloud Provider Admins have to manage this data — neither resource has a public API today, though both already have private `osac` CLI support (`osac create/describe storagetier`, `osac create/describe storagebackend`, confirmed merged in `fulfillment-service`). A public, tenant-facing Get/List API for `StorageTier` (not `StorageBackend`) is planned separately under OSAC-3014, to let VMaaS tenants see which tiers are available when selecting a disk tier during ComputeInstance creation (OSAC-1710); that public surface, and any UI built on it, is out of scope for this admin-only design — see Drawbacks.

Neither the OSAC-1110 nor the OSAC-1111 PRD states a UI requirement — unlike `ClusterVersion` (OSAC-1269), whose PRD explicitly required "The UI console supports catalog management for admins" (FR-9). An earlier revision of this document used that absence, plus the precedent of `NetworkClass` (a structurally similar resource with no CRUD UI in `osac-ui` today), to scope `StorageBackend` out entirely and treat it as read-only support data for the `StorageTier` UI. The OSAC-1111 design owner reviewed that scoping and confirmed the real Cloud Provider Admin workflow is incomplete without it: an admin registers a `StorageBackend` (vendor, endpoint, credentials) first, then composes `StorageTier`s on top of the registered backends, and needs to see and manage backend registrations through the same UI rather than falling back to the CLI or raw API calls partway through an otherwise-graphical workflow. This design now builds full CRUD for both resources on that basis.
Neither the OSAC-1110 nor the OSAC-1111 PRD states a UI requirement — unlike `ClusterVersion` (OSAC-1269), whose PRD explicitly required "The UI console supports catalog management for admins" (FR-9). Scope here is therefore determined by the actual Cloud Provider Admin workflow, not a PRD mandate: an admin registers a `StorageBackend` (vendor, endpoint, credentials) first, then composes `StorageTier`s on top of the registered backends. Splitting that workflow — full CRUD for `StorageTier` but only read-only visibility into `StorageBackend` — would force the admin back to the CLI or raw API calls partway through an otherwise-graphical task, for a resource that isn't meaningfully simpler or more static than `StorageTier` itself. This design builds full CRUD for both resources on that basis.

**Phasing, confirmed on the 2026-08-04 storage-scope call:** this design covers the Cloud Provider Admin (CSP admin) side only — registering backends and composing tiers. The tenant-consuming side (a tenant selecting a `StorageTier` for a disk, per OSAC-1710/OSAC-3014) is explicitly a later phase, owned by a future design, not this one. A second, related decision from that call: **tenants must remain completely unaware of the `StorageBackend` concept.** A tenant's only mental model is "storage tiers" — they never see, select, or need to know that a tier is backed by one or more registered backends. This UI (admin-only, no tenant surface at all) doesn't violate that by construction, but the constraint is recorded here because it binds any future tenant-facing work built on this data model: OSAC-3014's public `StorageTier` Get/List API must never expose `spec.backends`/`backendId`/provider/endpoint in its tenant-facing representation — only tier-level, tenant-appropriate properties (name, description, effective QoS).
This design covers the Cloud Provider Admin (CSP admin) side only — registering backends and composing tiers. The tenant-consuming side (a tenant selecting a `StorageTier` for a disk, per OSAC-1710/OSAC-3014) is a later phase, owned by a future design, not this one. A related, binding constraint: **tenants must remain completely unaware of the `StorageBackend` concept.** A tenant's only mental model is "storage tiers" — they never see, select, or need to know that a tier is backed by one or more registered backends. This UI (admin-only, no tenant surface at all) satisfies that trivially, but the constraint matters for what comes next: OSAC-3014's public `StorageTier` Get/List API must never expose `spec.backends`/`backendId`/provider/endpoint in its tenant-facing representation — only tier-level, tenant-appropriate properties (name, description, effective QoS).

### User Stories

Expand Down Expand Up @@ -379,4 +380,4 @@ Final: respond @ design 0.5.0 - 68284c8, workspace docs/OSAC-1110-1111-storage-u

> Context changed between draft and respond.

<!-- ai-workflow-provenance:{"schema_version":1,"provenance_kind":"session","workflow":"design","workflow_version":"0.5.0","ai_workflows":"68284c8","source_repo":"47288de","source_repo_branch":"docs/OSAC-1110-1111-storage-ui-design","commits_behind_main":25,"commits_ahead_main":3,"main_ref":"main","phases":["draft","revise","respond","respond","respond","respond","respond","revise","respond"],"authoring_modes":["skill"],"context_changed":true} -->
<!-- ai-workflow-provenance:{"schema_version":1,"provenance_kind":"session","workflow":"design","workflow_version":"0.5.0","ai_workflows":"68284c8","source_repo":"47288de","source_repo_branch":"docs/OSAC-1110-1111-storage-ui-design","commits_behind_main":25,"commits_ahead_main":3,"main_ref":"main","phases":["draft","revise","respond","respond","respond","respond","respond","revise","respond","revise","revise"],"authoring_modes":["skill"],"context_changed":true} -->
Loading