-
Outcome
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
67% To Do, 33% In Progress, 0% Done
-
False
-
Outcome Overview
The process of installing ARO (Classic) with a new release payload can be completely automated with no manual steps.
Success Criteria
Existence of a nightly ARO installation CI job, and the ability to configure a comparable job to run on an arbitrary pull request.
Expected Results (what, how, when)
Reduce delay between release of a new OCP version and offering it on ARO (Classic), potentially as far as zero (i.e. release ARO at OCP GA). By eliminating time-consuming manual processes (involving code rebases and library updates) that can realistically only be done once per release - and thus only begin after GA - we can shift testing left so that issues are detected either before they are created or at least prior to release branching. Verification of a new version in ARO can then occur in parallel to the OCP release testing. The ability to release simultaneously should be limited only by the capacity available to find and remedy any issues in ARO within the same timeframe as OCP release testing.
Historical ARO release delays after OCP GA:
OCP Release | Delay |
---|---|
4.17 | In Progress |
4.16 | In Progress |
4.15 | 7 months |
4.14 | 11 months |
4.13 | 5 months |
4.12 | 6 months |
Following completion of the required features, review the release delays for the following two OCP releases.
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).
- links to