Feature Overview (aka. Goal Summary)  

• OLM replaces the older version of the extensions with a newer version atomically either automatically or manually defined by the administrative personas.

Goals (aka. expected user outcomes)

• Admins can set an extension update policy either as automatically or manually so that OLM replaces the older version of the extensions with a newer version atomically.

• An update should be able to be rolled back by an admin (with F23) up until any custom code or conversion logic runs.

• When multiple extensions are updated to satisfy an update request, the update policy of each extension needs to be respected to allow admins to pin certain extensions to installed versions or certain types of updates (e.g. z-stream only).

• All versions along the update path should be allowed for selection by the user as the desired target version.

• OLM 1.0 will replace the current version of the Operator with the desired target version and users can check the progress of that transition, on the user-facing Operator API.

• OLM 1.0 now enables users to set operator updates to be applied automatically but are bound to patch releases only.

• OLM 1.0 enables an upgrade that ignores the upgrade edges to make it possible to force an update to a certain version, even if there is no direct path as per the graph metadata.

Requirements (aka. Acceptance Criteria):

Use Cases

• OLM 1.0 users can set an extension update policy either as automatically or manually so that OLM replaces the older version of the extensions with a newer version atomically.

• OLM 1.0 users can roll back an extension update (before the custom code/conversion logic runs/certain point of the update process) with the upcoming OLM 1.0 feature: F23 (Opt-in to fallback/rollback).

• OLM 1.0 users can set a distinct update policy for each extension to pin to a particular installed version or a certain type of update (e.g. z-stream only). In the case when multiple extensions are updated to satisfy an update request, the update policy of each extension will be respected.

• OLM 1.0 users can specify a specific version along the update path as the desired target version for the extension update.

• OLM 1.0 users can check the progress of that transition, on the user-facing Operator API.

• OLM 1.0 users can force an extension update to a specific version, even if there is no direct path as per the graph metadata.

• OLM 1.0 users can set operator updates to be applied automatically but are bound to patch releases only. 

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 an extension update policy” needs to be documented (in the context of “Administrator tasks”).
• The way “OLM 1.0 users can set distinct update policy to each extension to pin to a particular installed version or a certain types of updates (e.g. z-stream only)” needs to be documented (in the context of “Administrator tasks”).

• (“Operators > Administrator tasks” section) OLM 1.0 users know how to specify a specific version along the update path as the desired target and know how to check the progress of that transition, on the user-facing Operator API.  

• (“Operators > Administrator tasks” section) “OLM 1.0 users know how to force an extension update to a specific version, even if there is no direct path as per the graph metadata.