Uploaded image for project: 'OpenShift Console'
  1. OpenShift Console
  2. CONSOLE-3094

Support Conditional Updates (a.k.a. Targeted Edge Blocking)

XMLWordPrintable

    • Support Conditional Updates
    • False
    • None
    • False
    • Not Selected
    • To Do
    • 0% To Do, 0% In Progress, 100% Done

      Goal

      • Add the ability for users to select supported but not recommended updates.
      • Refine workflow when both "upgradeable=false" and "supported-but-not-recommended" updates occur

      Background
      RFE: for 4.10, Cincinnati and the cluster-version operator are adding conditional updates (a.k.a. targeted edge blocking): https://issues.redhat.com/browse/OTA-267

      High-level plans in https://github.com/openshift/enhancements/blob/master/enhancements/update/targeted-update-edge-blocking.md#update-client-support-for-the-enhanced-schema

      Example of what the oc adm upgrade UX will be in https://github.com/openshift/enhancements/blob/master/enhancements/update/targeted-update-edge-blocking.md#cluster-administrator.

      The oc implementation landed via https://github.com/openshift/oc/pull/961.

      Design

      • Use case 01: "supported but not recommended" occurs to the latest version:
        • Add an info icon next to the version on update path with a pop-over to explain about why updating to this version is supported, but not recommended and a link to known risks
        • Identify the difference in "recommended" versions, "supported but not recommended" versions, and "blocked" versions (upgradeable=false) in the + more modal.
        • The latest version is pre-selected in the dropdown in the update modal with an inline alert to inform users about supported-but-not-recommended version with link to known risks. Users can choose to update to another recommended versions, update to a supported-but-not-recommended one, or wait.
        • The "recommended" and "supported but not recommended" updates are separated in the dropdown.
        • If a user selects a "recommended" update, the inline alert disappears.
      • Use case 02: When both "upgradeable=false" and "supported but not recommended" occur:
        • Add an alert banner to explain why users shouldn’t update to the latest version and link to how to resolve on the cluster settings details page. Users have the options to resolve the issue, update to a patch version, or wait.
        • If users open the update modal without resolving the "upgradeable=false" issue, the next recommended version is pre-selected. An expandable link "View blocked versions (#)" is included under the dropdown to show "upgradeable=false" versions with resolve link.
        • If users resolve the "upgradeable=false" issue, the cluster settings page will change to use case 01
        • Question: Priority on changing the upgradeable=false alert banner in update modal and blocked versions in dropdown

      See design doc: https://docs.google.com/document/d/1Nja4whdsI5dKmQNS_rXyN8IGtRXDJ8gXuU_eSxBLMIY/edit#

      See marvel: https://marvelapp.com/prototype/h3ehaa4/screen/86077932

        1. 14 copy 7.png
          164 kB
          Thi Le
        2. Cluster Settings - Update 2 Copy 13.png
          135 kB
          Thi Le
        3. Cluster Settings - Update 2 Copy 26.png
          144 kB
          Thi Le
        4. Conditional update workflow.png
          363 kB
          Thi Le

              rh-ee-jonjacks Jon Jackson
              mehall-1 Megan Hall
              YaDan Pei YaDan Pei
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: