Goal

• Enhance the value of the Releases page and allow users to understand the recommended update paths as it relates to their current fleet.
  • Ex., show users how to get from 4.3 and 4.8 beyond just saying they can. This is important because today, you may have to take multiple hops to get to your ideal version.
• Our main focus would be on surfacing the update path component as it pertains to “my current fleet” and any relevant version information that would be helpful in making decisions. There is a lot of value in surfacing how customers can get "Cluster A" as far as they can down the line, without making them go outside of OCM to see that path every time.

Background
The Lab's App team built an upgrade graph tool (https://access.redhat.com/labs/ocpupgradegraph).

We would like to lift and shift this into OCM and find away to leverage the functionality in a way that in is meaningful and makes sense inside of OCM. 

• Leverage the current labs app's capability to and move the following functionality into OCM:
  • See the current graph of a channel 
  • See how to move the most effectively between versions
  • See how / when channel changes occur (errata on the channel push/pulls) - via git history or errata, doesn't matter. 
  • See how to get attachments (clients) for a version or be linked to where you can get this.
• Not sure if this is still relevant if we leverage the labs app's backend:
  • Find out if the new OTA work will support the ability to transverse multiple y-streams at a time. (https://github.com/openshift/cincinnati-graph-data/pull/526 we should be able to shift channels immediately and then just follow recommended updates, instead of having to update before switching channels)
• The benefit to this tool living in OCM is that it knows a lot about you and your clusters, so ideally can query Cinci with the same info as a cluster and get the same result back, but in the UI instead. We know your channel, your version, your EBS number, your cluster ID - I assume one or all of those can get us the right result? Overall this is the benefit of having this in OCM instead of another property. I'll also stress that the flattening out the upgrade graph from a ball of options into a linear path makes it so much more understandable. You can imagine reading that over the phone to someone and being successful vs trying to choose your own adventure given a graph with 40 pathways.

Design 

• From the release page: Allow users to make sense of the release page information as it relates to their clusters by surfacing a notification at the top of the page when clusters in their fleet have available updates. Clicking the link in the alert will navigate users to a pre-filtered cluster list that only shows clusters with available updates.
• From the cluster list (and details pages): users click the update action for any OCP cluster. This action opens a modal that renders the update path and provides information in context that users can take immediate action on. If applicable, surface an upgradable=false message (similar to what we have in OCP) to let users know why they may not see the most recent minor version available.
• From the modal: send users directly into the OCP console to initiate the update, providing a clear path inside of OCM to OCP.

Assets 

• WIP Doc: https://docs.google.com/document/d/1NX6U43eYWH7vzYRrefd5p2C5j3eOQx1x5gXFG_QzBGc/edit#heading=h.vj53sho39lu0
• WIP Marvel:  Mock-ups that do not include ALL of the Laps App requirements (new mockups in progress)