Jaeger-operator: How should Jaeger components be updated to new version via OLM

[objectiser]

Recently saw a demo where components managed by an operator were (rolling) updated to a new version by:

• User being informed there was a new version of the operator
• User manually deciding to perform the update
• When operator was updated, it scanned for its managed resources and then updated them

The presenter said that once confident with the operator, the user can decide to automatically allow the operator to be updated when a new version becomes available - so it can be more automated (i.e. doesn't always require manual ack).

Do we need to do anything to also support this way of working with OLM?

One thing to consider - does the version listed in the operator manifest, or jaeger.version need to be major.minor.patch or is major.minor ok?

OLM will probably only trigger the mechanism when a new cluster service version (csv) definition is registered - which might mean a csv per patch version - which also means that the manifest would need to be tied to that patch version.

For the jaeger components, it would probably be best on the logic handling the scanning and updating of component versions. If jaeger.version has major.minor then it could detect most recent version available (possibly) and compare to running - but if does not have access to that information, then having the major.minor.patch version in the jaeger.version file might be the only way to know the most recent version known by the operator.

Would prefer to use major.minor in jaeger.version to avoid having to release a new version of the operator whenever there is a patch release of the jaeger images.

[jpkrohling]

Do we need to do anything to also support this way of working with OLM?

From our operator's perspective, it would require only doing backwards compatible changes, or creating a script that would update the data that backs our operator. Currently, we have no data other than the CRs themselves, so, whenever we change the model, we have to:

• provide sensible defaults for new properties, so that we won't require values that don't exist for old CRs
• alias properties instead of renaming/moving them
• ignore properties instead of removing them

For the jaeger components, it would probably be best on the logic handling the scanning and updating of component versions

About updating the underlying Jaeger instance, we are tracking it here as part of #42

[jpkrohling]

To be clear, I think there are two cases here:

1. New version of Jaeger
2. New version of the Jaeger Operator

We may provide a property in the CR to fix Jaeger at a specific version (see #42). Upon change of this property, the operator handles the update to the user's defined version.

Then, there's the capability of updating the operator itself, which currently does not involve any work (see comment above), IIRC.

Both cases might be combined, as a new version of the operator might come with a new Jaeger version (Operator 1.13 -> Jaeger 1.13).

[jpkrohling]

My understanding is that we settled with the one to one use case: one version of the Jaeger Operator corresponds to one version of the underlying Jaeger. When the Operator is updated, it brings all the managed Jaeger instances to its supported version.