This repository was archived by the owner on Sep 9, 2026. It is now read-only.
Repository navigation
MGMT-23977: Implement per-tier StorageClass resolution in Tenant controller #199
Merged
openshift-merge-bot
merged 3 commits into
osac-project:main
from
zszabo-rh:feature/MGMT-23977-per-tier-resolution
May 4, 2026
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: When should a Tenant be considered not ready due to StorageClass issues?
Currently
StorageClassNotReadyis emitted only when zero tiers resolve. If some tiers resolve and others have duplicates, the Tenant is Ready and the only signal is aDuplicateStorageClassevent.This raises a question: should a Tenant be Ready when a tier that was explicitly configured for it doesn't resolve? For example, if an admin creates a tenant-specific "fast" StorageClass, then accidentally introduces a duplicate, the Tenant stays Ready. The misconfiguration is only visible in events, not in the phase.
Before deciding on the event model (
StorageClassNotReadyvsTenantNotReadyvsTenantTierNotReady), it's worth clarifying the readiness semantics:Option 1: At least one tier resolves = Ready (current, per EP #32)
StorageClassNotReadyonly fires when all tiers failOption 2: All discovered tiers must resolve = Ready
Option 3: Spec-driven required tiers
requiredTiersto TenantSpec, controller checks exactly thoseThis PR implements Option 1 per the EP. Raising it here since the answer shapes what events we emit and when. Happy to discuss offline.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think option 1 is the right starting point for v1, a misconfiguration in one tier shouldn't block the entire tenant when other tiers are fine.
The DuplicateStorageClass event already signals per-tier misconfigurations. If we find that operators need stronger guarantees, option 3 would be the cleanest future evolution, it makes the contract explicit without overloading the resolution logic.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about the event hierarchy a bit more. Even with Option 1, we could separate cause from effect in the event naming:
Tenant-level (all tiers failed, tenant is Progressing):
TenantNotReady: emitted when no tier resolves at allTier-level (specific tier failed, tenant may still be Ready):
TenantStorageTierNotReady: emitted per failing tier, with reason in the message:DuplicateStorageClass: multiple SCs matched for the tierStorageClassMissing: no SC found for the tier (no tenant-specific, no Default)This separates what happened (cause) from the impact (effect), and also future-proofs for new failure reasons without changing the event structure. Today
DuplicateStorageClassserves as both the cause and the event name, which works but conflates the two.One thing to consider: for
TenantStorageTierNotReadyto be meaningful, we'd need to know which tiers are expected for a tenant. Otherwise we'd fire events for tiers that aren't relevant to the tenant (e.g., a shared Default "archive" tier that the tenant doesn't use). This might circle back to tracking enabled tiers per tenant, either in the spec or derived from discovered SCs. This can be tackled in post v1.0, if we identify the events are noisy or just as part of event hardening.WDYT?