<--- Cut-n-Paste the entire contents of this description into your new Epic --->
- Break the upgrade into three (or more) discrete steps each of which can be rolled back before moving on to the next, proposed steps would be Control Plane, Worker Nodes, and Workload Enablement
- Admins continuously ask us for rollback especially in the context of minor version upgrades
- However, it's not likely that we can deliver a complete rollback of a completed upgrade so we should break it up into smaller components which each can be rolled back if necessary but the sum of all could not. The admin will be responsible for checkpointing and deciding.
- Design how we'd decompose the upgrade down beyond our current capabilities
- Design which components go where, for instance is SDN Control Plane or Workload Enablement, are OpenShift API & Controllers part of Control Plane or only core Kubernetes?
- Maybe there's a better way, halt at each runlevel and seek admin approval? Halt at increments of 10s across runlevels, bucket things into those?
- Must be able to measure each discrete step duration and sum those steps to compare against current norms
- CI - MUST be running successfully with tests automated
- Release Technical Enablement - Provide necessary release enablement details and documents.
- Hypershift has gone through an exercise to split things into control, dataplane, and worker https://docs.google.com/document/d/1BDoo3hchNz1C3QSeixnGMX6HaYCS11hp6J4j-9ZNL3E/edit#heading=h.t9umwnbsnf1
- CI - CI is running, tests are automated and merged.
- Release Enablement <link to Feature Enablement Presentation>
- DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
- DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
- DEV - Downstream build attached to advisory: <link to errata>
- QE - Test plans in Polarion: <link or reference to Polarion>
- QE - Automated tests merged: <link or reference to automated tests>
- DOC - Downstream documentation merged: <link to meaningful PR>