Uploaded image for project: 'Operator Runtime'
  1. Operator Runtime
  2. OPRUN-3015

Operator version pinning and pivoting

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Major Major
    • openshift-4.14
    • None
    • None
    • Operator version pinning and pivoting
    • False
    • None
    • False
    • Not Selected
    • To Do
    • OCPSTRAT-450 - [Phase 1 MVP/Tech Preview] OLM 1.0 - Extension updates (F10)
    • OCPSTRAT-450[Phase 1 MVP/Tech Preview] OLM 1.0 - Extension updates (F10)
    • 0
    • 0% 0%
    • 0

      Epic Goal

      • Enable cluster administrators to pin to a specific version of an operator

      Why is this important?

      • Cluster admins often have staging clusters and production clusters. Once they have validated an operator version in the staging cluster, they need to be able to deploy that exact operator version into the production cluster later, even if more recent versions of the operator have been released into the catalog.

      Scenarios

      1. As a cluster admin, I would like to choose a specific version of an operator to install in my cluster
      2. As a cluster admin, I would like to pin to a specific version of an operator and avoid receiving automatic upgrades
      3. As a cluster admin I would like to be able to upgrade/downgrade to an arbitrary version of the operator without having to uninstall and reinstall the operator.

      Acceptance Criteria

      • When a cluster admin specifies invalid syntax for an operator version in the Operator API, the creation/update is rejected during admission
      • When a cluster admin specifies a valid syntax for an operator version in the Operator API, but that version does not exist in the catalog, the Operator status eventually reports that the version is not available
      • When a cluster admin specifies a valid syntax for an operator version in the Operator API, that version is eventually installed.
      • When a cluster admin changes the value of the operator version in the Operator API, and the new version is not found, the Operator keeps the previous version installed and eventually contains an updated status that reports that the new version was not found.
      • When a cluster admin changes the value of the operator version in the Operator API, and the new version exists, the change proceeds, regardless of any operator-defined upgrade graphs (i.e. upgrade graphs are ignored in this phase)
      • When a cluster admin specifies a valid and existing operator version in the Operator API, but the cluster adminĀ also specifies a channel in which the version is not present, the Operator status eventually reports that version is not available in the specified channel.

      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 - Downstream documentation merged: <link to meaningful PR>

            Unassigned Unassigned
            jlanford@redhat.com Joe Lanford
            Jian Zhang Jian Zhang
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: