Uploaded image for project: 'OpenShift Container Platform (OCP) Strategy'
  1. OpenShift Container Platform (OCP) Strategy
  2. OCPSTRAT-450

[Phase 1 MVP/Tech Preview] OLM 1.0 - Extension updates (F10)

XMLWordPrintable

    • Strategic Product Work
    • False
    • Hide

      None

      Show
      None
    • False
    • OCPSTRAT-27OLM V1: Operators, Operator Lifecycle Management, and Operator Hub
    • 0% To Do, 0% In Progress, 100% Done
    • 0
    • Program Call

      Feature Overview (aka. Goal Summary)  

      • Note: This feature is aimed to track the progress of Phase 1 MVP scope for the OLM 1.0
        • i.e., "IsMVP: YES" in the table of Functional Requirements.
      • OLM replaces the older version of the extensions with a newer version atomically after the target version is defined by the administrative personas.

      Goals (aka. expected user outcomes)

      • All versions of a package within the channel of a catalog should be allowed for selection by the user as the desired target version.
      • OLM replaces the older version of the extensions with a newer version atomically.

       

      Requirements (aka. Acceptance Criteria):

      Requirement Notes isMvp?
      As extensions get updated, OLM replaces the older version of the extensions with a newer version atomically. No update path concept in this release --> No auto update YES
      All versions within the channel in the catalog should be allowed for selection by the user as the desired target version. No update path concept in this release. YES
      CI - MUST be running successfully with test automation This is a requirement for ALL features. YES
      Release Technical Enablement Provide necessary release enablement details and documents. YES

      Use Cases

      • OLM 1.0 users can set a target version manually so that OLM replaces the older version of the extensions with a newer version atomically.
        • No update path concept in this release --> No auto-update.

      Definition of Done / Acceptance criteria

      • All use cases above are implemented and meet the requirements (requirements for MVP takes priority).
      • Although not part of this feature, the design should take how F23 (Opt-in to fallback/rollback) can be implemented into consideration.

      Background, and strategic fit

      This is part of a larger effort to re-design vital parts of the OLM APIs and conceptual models to fit the use case of OLM in managed service environments, GitOps-controlled infrastructure and restrictive self-managed deployments in Enterprise environments. You can learn more about it here: https://docs.google.com/document/d/1LX4dJMbSmuIMn98tCiBaONmTunWR6zdUJuH-8uZ8Cno/edit?usp=sharing

      Documentation Considerations

      • The way “OLM 1.0 users can set a  target version” needs to be documented (in the context of “Administrator tasks”).

              rhn-coreos-tunwu Tony Wu
              rhn-coreos-tunwu Tony Wu
              Jian Zhang Jian Zhang
              Matthew Werner Matthew Werner
              Joe Lanford Joe Lanford
              Senthamilarasu S Senthamilarasu S
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: