1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00

OLMv1 4.16: Support legacy OLM upgrade constraint semantics

This commit is contained in:
Alex Dellapenta
2024-06-11 15:48:12 -06:00
committed by openshift-cherrypick-robot
parent 9966829100
commit de21cbcef8
5 changed files with 70 additions and 20 deletions

View File

@@ -209,7 +209,9 @@ endif::[]
:olm: OLM
//Initial version of OLM that shipped with OCP 4, aka "v0"
:olmv0: legacy OLM
:olmv0-caps: Legacy OLM
:olmv0-first: legacy Operator Lifecycle Manager (OLM)
:olmv0-first-caps: Legacy Operator Lifecycle Manager (OLM)
//Next-gen (OCP 4.14+) Operator Lifecycle Manager, aka "v1"
:olmv1: OLM 1.0
:olmv1-first: Operator Lifecycle Manager (OLM) 1.0

View File

@@ -1,25 +1,13 @@
// Module included in the following assemblies:
//
// * operators/olm_v1/olmv1-installing-an-operator-from-a-catalog.adoc
// * operators/olm_v1/arch/olmv1-operator-controller.adoc
// Moved to _unused_topics dir with 4.16 in case useful in a later release of OLMv1.
:_mod-docs-content-type: CONCEPT
[id="olmv1-semver-support_{context}"]
= Support for semantic versioning
Support for link:https://semver.org/[semantic versioning (semver)] is enabled in {olmv1} by default. Operator and extension authors can use the semver standard to define compatible updates.
{olmv1-first} can use an Operator or extension's version number to determine if an update can be resolved successfully.
Cluster administrators can define a range of acceptable versions to install and automtically update. For Operators and extensions that follow the semver standard, you can use comparison strings to define to specify a desired version range.
[NOTE]
====
{olmv1} does not support automatic updates to the next major version. If you want to perform a major version update, you must verify and apply the update manually. For more information, see "Forcing an update or rollback".
====
== Major version zero releases
[id="olmv1-major-version-zero_{context}"]
= Major version zero releases
The semver standard specifies that major version zero releases (`O.y.z`) are reserved for initial development. During the initial development stage, the API is not stable and breaking changes might be introduced in any published version. As a result, major version zero releases apply a special set of update conditions.

View File

@@ -0,0 +1,26 @@
// Module included in the following assemblies:
//
// * operators/olm_v1/olmv1-installing-an-operator-from-a-catalog.adoc
// Moved to _unused_topics dir with 4.16 in case useful in a later release of OLMv1.
:_mod-docs-content-type: CONCEPT
[id="olmv1-semver-support_{context}"]
= Support for semantic versioning
{olmv1-first} supports link:https://semver.org/[semantic versioning (semver)] when explicitly enabled. Cluster extension authors can use the semver standard to define compatible updates.
[NOTE]
====
In {product-title} 4.16, {olmv1} uses {olmv0} semantics by default.
====
{olmv1} can use an extension's version number to determine if an update can be resolved successfully.
Cluster administrators can define a range of acceptable versions to install and automatically update. For extensions that follow the semver standard, you can use comparison strings to specify a desired version range.
[NOTE]
====
{olmv1} does not support automatic updates to the next major version. If you want to perform a major version update, you must verify and apply the update manually. For more information, see "Forcing an update or rollback".
====

View File

@@ -97,7 +97,7 @@ You can make patch release comparisons by using the tilde (`~`) comparison opera
|===
You can use the caret (`^`) comparison operator to make a comparison for a major release. If you use a major release comparison before the first stable release is published, the minor versions define the API's level of stability. In the semantic versioning (SemVer) specification, the first stable release is published as the `1.0.0` version.
You can use the caret (`^`) comparison operator to make a comparison for a major release. If you make a major release comparison before the first stable release is published, the minor versions define the API's level of stability. In the semantic versioning (semver) specification, the first stable release is published as the `1.0.0` version.
.Example major release comparisons
[options="header"]

View File

@@ -13,7 +13,7 @@ In the current Technology Preview release of {olmv1-first}, you manage catalogs
:FeatureName: {olmv1}
include::snippets/technology-preview.adoc[]
[id="prerequisites_olmv1-installing-an-operator-from-a-catalog"]
[id="prerequisites_{context}"]
== Prerequisites
* Access to an {product-title} cluster using an account with `cluster-admin` permissions
@@ -69,11 +69,45 @@ include::modules/olmv1-updating-an-operator.adoc[leveloffset=+1]
* xref:../../operators/olm_v1/olmv1-installing-an-operator-from-a-catalog.adoc#olmv1-about-target-versions_olmv1-installing-operator[Example custom resources (CRs) that specify a target version]
* xref:../../operators/olm_v1/olmv1-installing-an-operator-from-a-catalog.adoc#olmv1-version-range-comparisons_olmv1-installing-operator[Version comparison strings]
include::modules/olmv1-semver-support.adoc[leveloffset=+2]
[id="upgrade-constraint-semantics_{context}"]
== Upgrade constraint semantics
When determining upgrade edges for an installed cluster extension, {olmv1-first} supports {olmv0} semantics starting in {product-title} 4.16. This support follows the behavior from {olmv0}, including `replaces`, `skips`, and `skipRange` directives, with a few noted differences.
By supporting {olmv0} semantics, {olmv1} now honors the upgrade graph from catalogs accurately.
.Differences from original {olmv0} implementation
* If there are multiple possible successors, {olmv1} behavior differs in the following ways:
** In {olmv0}, the successor closest to the channel head is chosen.
** In {olmv1}, the successor with the highest semantic version (semver) is chosen.
* Consider the following set of file-based catalog (FBC) channel entries:
+
[source,yaml]
----
# ...
- name: example.v3.0.0
skips: ["example.v2.0.0"]
- name: example.v2.0.0
skipRange: >=1.0.0 <2.0.0
----
+
If `1.0.0` is installed, {olmv1} behavior differs in the following ways:
+
--
** {olmv0-caps} will not see an upgrade edge to `v2.0.0` because `v2.0.0` is skipped and not on the `replaces` chain.
** {olmv1} will see the upgrade edge because {olmv1} does not have a concept of a `replaces` chain. {olmv1} finds all entries that have a `replace`, `skip`, or `skipRange` value that covers the currently installed version.
--
[NOTE]
====
Support for semantic versioning (semver) upgrade constraints was introduced in {product-title} 4.15 but disabled in 4.16 in favor of {olmv0} semantics during this Technology Preview phase.
====
[role="_additional-resources"]
.Additional resources
* xref:../../operators/olm_v1/olmv1-installing-an-operator-from-a-catalog.adoc#olmv1-forcing-an-update-or-rollback_olmv1-installing-operator[Forcing an update or rollback]
* xref:../../operators/understanding/olm/olm-workflow.adoc#olm-upgrades_olm-workflow[{olmv0-caps} upgrade semantics]
include::modules/olmv1-version-range-support.adoc[leveloffset=+2]