-
Outcome
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
None
-
None
-
100% To Do, 0% In Progress, 0% Done
-
Not Selected
-
0
Outcome Overview
This Outcome will deliver a zero-downtime, operator-driven major version upgrade mechanism for Red Hat OpenStack services on OpenShift, specifically from version 18 to 19.
This directly addresses critical end-customer requirements for maintenance operations, enabling them to adopt new OpenStack versions (RHOSO 19) without consuming their stringent downtime budgets (e.g., 5 or 6 nines availability targets).
This solidifies the operator-native approach for all lifecycle management, including major version upgrades, proving the platform's maturity and suitability for Tier 1 telco/NFV and enterprise workloads. It shifts the perception of a major upgrade from a complex, high-risk project to a controlled, automated operational task.
This will unblock customer adoption of RHOSO 19, especially for those with "in-service" upgrade mandates, directly contributing to product revenue growth and improving customer satisfaction/Net Promoter Score (NPS) within the target segment.
Success Criteria
For this outcome to be considered delivered, the following must be true:
- Operator Control: The complete major version upgrade process from RHOSO 18 to RHOSO 19 is fully orchestrated and managed by the Red Hat OpenStack operators, requiring no manual intervention in the critical path.
- Zero Downtime for Workloads: The OpenStack data plane remain continuously operational and available to external workloads throughout the entire upgrade procedure (18 ->19).
- Minimal API Downtime: The cumulative time during which the OpenStack Core APIs are unoperational (unable to serve API requests) must be documented, measured, and demonstrably minimized to the lowest technically feasible duration, and must be less than 15 minutes in a representative performance/scale environment.
- Time-Bound Execution: The operator-driven major upgrade procedure (18 -> 19) must be successfully executed end-to-end (including verification) within a maximum time limit of two hours in a representative performance/scale environment.
- Fail Forward/Back Capability: A documented, automated procedure exists to either revert to the stable RHOSO 18 version or complete the RHOSO 19 upgrade (fail forward) within a dedicated two-hour window should the main upgrade fail or exceed the initial time limit.
- Documentation & Support: The validated, operator-driven 18 -> 19 upgrade path is fully documented and officially supported for Red Hat OpenStack on OpenShift customers.
Expected Results (what, how, when)
| Expected Result | What will you measure? | When will you measure it? |
| Achieve Minimal API Downtime (Core Mechanism Success) | Actual measured duration (in minutes/seconds) during which the OpenStack Core APIs are unoperational during the final 18 -> 19 upgrade test. Target: Minimized, <10 minutes. (Link to: Internal Performance & CI/CD Logs/Reports) | CI jobs |
| Meet Total Upgrade Window (Operational Success) | Actual end-to-end major upgrade time (18 ->19) in the certified performance environment. Target: < 120 minutes. | Performance & scale testing |
| Unblock Telco/Tier 1 Adoption of RHOSO 19 | Number of key customer PoCs/trials moving to RHOSO 19 deployment that previously cited "major upgrade downtime/risk" as a blocking factor. | TBD |
Post Completion Review – Actual Results
After completing the work (as determined by the "when" in Expected Results above), list the actual results observed / measured during Post Completion review(s).
- is Informed by
-
OSPRH-18107 develop plan for OSP19 upgrades
-
- Closed
-