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

[upstream] Refactor legacy upgrade constraint semantics behind an interface

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Done
    • Icon: Major Major
    • None
    • None
    • None
    • Upstream
    • 5
    • False
    • None
    • False
    • OCPSTRAT-78 - [Phase 2 MVP/Tech Preview] OLM 1.0 - Extension updates (F10)
    • INKEY$ (OPRUN 243)

      Description:

      Introduce an interface that semVer and Legacy upgrade semantics can implement.
      Refactor the legacy upgrade constraint semantics behind the interface as described in the RFC.

      Solver
      The solver needs to be able to switch between upgrade constraint semantics based on rules defined above (see Fig 1).

      Note that no matter the positions of ForceSemverUpgradeConstraints feature gate and value of .spec.upgradeConstraintPolicy we still need to apply Operator’s other constraints. This means that .spec.channel and .spec.version need to be taken into account during the resolution process, if these fields were set:

      • If the .spec.version field specifies a version or range, resolution must choose from a version that falls with that version or range
      • If the .spec.channel field specifies a channel, resolution must choose from a version that is a member of that channel

      Refactoring of existing support of legacy semantics
      In preparation of introducing of semver we need to:

      • Define an interface common for all the semantics
      • Refactor existing code which provides support of legacy semantics to match the interface

      The idea is that there will be a function with roughly the following signature:

       type Successors func(currentBundle string) []string

      Where currentBundle uniquely identifies the currently installed bundle and the return value is a slice uniquely identifying possible successors.
      For the legacy semantics possible successors will be bundles according to the replaces/skips/skipRange.

      Acceptance Criteria:

      Reporting resolution issues must also happen as described in the RFC:

      In case of errors during the resolution - issues must be reported via status update of the Operator. This applies to all semantics and all positions of the feature gate.

      Operator is expected to set or update the condition of type Resolved to False with Reason set to ResolutionFailed and provide a meaningful error message.

       conditions, metav1.Condition{
           Type:               operatorsv1alpha1.TypeResolved,
           Status:             metav1.ConditionFalse,
           Reason:             operatorsv1alpha1.ReasonResolutionFailed,
           Message:            message,
           ObservedGeneration: generation,
      }

            mradchuk@redhat.com Mikalai Radchuk
            agreene1991 Alexander Greene (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: