-
Story
-
Resolution: Unresolved
-
Blocker
-
None
-
None
-
False
-
None
-
False
-
-
There are some differences between how OSSM 2 and 3 managed operator and component versions, for example:
- OSSM 2 used OSSM versions in the SMCP; OSSM 3 will use Istio versions
- OSSM 2 only allowed specifying a minor release; OSSM 3 will allow specifying a patch release.
- OSSM 3 will introduce an operator channel per release...
- Possibly more...
It would be best if this section used real version examples with OSSM 3 GA and also if the automatic upgrade feature was available. So, we'll defer this issue until the engineering work is complete - closer to GA.
Comment from dgrimm@redhat.com that originated it:
maybe somewhere in this section we should mention that users will now have to select a patch version (e.g. v1.21.3 instead of just v1.21) and patch updates are not applied automatically anymore. also, we now use upstream Istio versions in the spec.version field instead of OSSM version. customers can see the versions supported by the operator by runningoc explain istios.spec.version
Some text I started to write, but is not complete...
The OpenShift Service Mesh 2 operator managed multiple components under an umbrella product version - for example, the final product version was 2.6, which included components such as Istio 1.20. This version was specified in the `ServiceMeshControlPlane` using the `version` field. The operator used the same version schema, but also managed older sets of components. For example, the OpenShift Service Mesh 2.6 operator managed OpenShift Service Mesh 2.6 components as well as OpenShift Service Mesh 2.5 components. As the OpenShift Service Mesh 3 operator is only responsible for managing Istio, it uses the Istio release as its sole component version. For example, with the OpenShift Service Mesh 3.0 operator, the `Istio` release may