Epic Goal

The OCP lifecycle will be enhanced to support rollback for z-streams starting with OCP 4.16. 
watch this space: https://issues.redhat.com/browse/OCPSTRAT-975

Why is this important?

Customers need faster recovery from failed OCP z-stream updates and need to lower their risk when applying updates.

Scenarios

In ACM, a user can multi-select and initiate OCP cluster update for both .y releases and .z releases. 
In ACM, during OCP cluster update scenarios for .z releases, we will need to be aware of how to also engage a rollback experience.

In ACM, a user can design a policy and initiate a fleet of OCP cluster updates. We need to be mindful of how to initiate a rollback experience from policy.

Perhaps TALM needs to be involved as well.

Acceptance Criteria

A user can successfully navigate to see updating OCP clusters from their ACM console and initiate a multi-select rollback.

A user can successfully list out all updating OCP clusters from their CLI and initiate a rollback activity.

Dependencies (internal and external)

1. OCPSTRAT-975
2. TALM

Previous Work (Optional):

1. ...

Open questions:

1. If the update is in the midst of failing, eg, a single node OpenShift and the API server is jacked up, how can ACM help with rollback?

Done Checklist

• 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 - Doc issue opened with a completed template. Separate doc issue
  opened for any deprecation, removal, or any current known
  issue/troubleshooting removal from the doc, if applicable.