-
Epic
-
Resolution: Done
-
Undefined
-
None
-
None
-
None
-
ClusterVersion status should report current target release's multi-arch-ness (tech-preview)
-
Quality / Stability / Reliability
-
False
-
-
False
-
Not Selected
-
None
-
None
-
None
Epic Goal
Tech-preview in 4.18, ClusterVersion status.desired should grow an architecture property reporting Multi if the target release is multi-architecture.
Why is this important?
This allows for some ImageStream-handling optimizations, see MULTIARCH-4552, and this enhancement section.
Scenarios
See testing notes in MULTIARCH-4556.
Dependencies
The API approval team needed to approve openshift/api#2024, and the updates team needed to pull that into the cluster-version operator and wire it up (cvo#1110 and cvo#1111), all of which happened under MULTIARCH-4559.
Contributing Teams
- Development - wking and the API reviewers.
- Documentation - no docs required; we don't expect customers to care about this, and the ClusterVersion API type docs are autogenerated, so they'll pick it up without more work
- QE - wking put testing notes in
MULTIARCH-4559. QE can check more if they like, but the multi-arch folks will also be exercising this in MULTIARCH-4552, so it probably doesn't need additional QE validation. - PX -
- Others -
Acceptance Criteria
See testing notes in MULTIARCH-4559.
Drawbacks or Risk
I tried to push back on this as overly complicated, but was eventually convinced by these arguments.
Done - Checklist
- CI Testing - Tests are merged and completing successfully. No test coverage outside of cvo#1110's unit tests.
- Documentation - Content development is complete. No docs needed; customers are unlikely to care.
- QE - Test scenarios are written and executed successfully. No QE currently planned; multi-arch will excercise in MULTIARCH-4552.
- Technical Enablement - Slides are complete (if requested by PLM). No technical-enablement expected.
- Other
- is blocked by
-
MULTIARCH-4559 CVO should expose the payload type through a field in its status
-
- Closed
-