Uploaded image for project: 'OpenShift Over the Air'
  1. OpenShift Over the Air
  2. OTA-1272

Re-prioritize the default update recommendations by freshness

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Done
    • Icon: Normal Normal
    • None
    • None
    • None
    • 5
    • OTA 260

      We currently show all the recommended updates in decreasing order with --include-not-recommended to see all the updates-with-assessed-risks in decreasing order.  But sometimes users want to update to the longest-hop, even if there are known risks.  Or they want to read about the assessed risks, in case there's something they can do to their cluster to mitigate a currently-assessed risk before kicking off the update.  This ticket is about adjusting oc's output to order roughly by release freshness.  For example, for a 4.y cluster in a 4.(y+1) channel:

      • 4.(y+1).tip
      • 4.y.tip
      • 4.(y+1).(tip-1)
      • 4.y.(tip-1)
        ...

      Because users are more likely to care about 4.(y+1).tip, even if it has assessed risks, than they are to care about 4.y.reallyOld, even if it doesn't have assessed risks.

      Show some number of these by default, and then use --show-outdated-versions or similar to see all the results.

      See Scott here and me in OTA-902 both pitching something in this space.

      Blocked on OTA-1271, because that will give us a fresh, tech-preview subcommand, where we can iterate without worrying about breaking existing users, until we're happy enough to GA the new approach.

      For example, on 4.12.16 in fast-4.13, oc adm upgrade will currently show between 23 and 91 recommended updates (depending on your exposure to declared update risks):

      cincinnati-graph-data$ hack/show-edges.py --cincinnati https://api.openshift.com/api/upgrades_info/graph fast-4.13 | grep '^4[.]12[.]16 ->' | wc -l
      23
      cincinnati-graph-data$ hack/show-edges.py --cincinnati https://api.openshift.com/api/upgrades_info/graph fast-4.13 | grep '^4[.]12[.]16 ' | wc -l
      91
      

      but showing folks 4.12.16-to-4.12.17 is not worth the line it takes, because 4.12.17 is so old, and customers would be much better served by 4.12.63 or 4.12.64, which address many bugs that 4.12.17 was exposed to. With this ticket, oc adm upgrade recommend would show something like:

      Recommended updates:
      
        VERSION                   IMAGE
        4.12.64 quay.io/openshift-release-dev/ocp-release@sha256:1263000000000000000000000000000000000000000000000000000000000000
        4.12.63 quay.io/openshift-release-dev/ocp-release@sha256:1262000000000000000000000000000000000000000000000000000000000000
      
      Updates with known issues:
      
        Version: 4.13.49
        Image: quay.io/openshift-release-dev/ocp-release@sha256:1349111111111111111111111111111111111111111111111111111111111111
        Recommended: False
        Reason: ARODNSWrongBootSequence
        Message: Disconnected ARO clusters or clusters with a UDR 0.0.0.0/0 route definition that are blocking the ARO ACR and quay, are not be able to add or replace nodes after an upgrade https://access.redhat.com/solutions/7074686
      
      There are 21 more recommended updates and 67 more updates with known issues.  Use --show-outdated-versions to see  all older updates.
      

              trking W. Trevor King
              trking W. Trevor King
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: