MAISTRA-985 track operator version on custom resources

[rcernich]

Signed-off-by: rcernich rcernich@redhat.com

[rcernich]

I've repurposed the ObservedGeneration field so that it's formatted as version-generation, e.g. 1.0.0-1 (operator version 1.0.0, cr generation 1).

That said, the upgrade fails because the labels are changed on the deployment template specs (we set maistra-version label there). We'll need to figure out how to handle this (probably best to omit this from the deployment.spec.template.spec.labels).

[luksa]

I'm not sure changing the ObservedGeneration is a good idea, since it is always just a simple integer in all other Kubernetes resources. I'm afraid deviating from the convention might end up biting us in the future.

Also, do people need the operator version or the service mesh version? I don't see why the operator version is even important here.

[knrc]

Also, do people need the operator version or the service mesh version? I don't see why the operator version is even important here.

The operator version may be important in future when we have multiple streams however the service mesh version is more likely to be the useful in the longer term especially when we have support for multiple versions.

[rcernich]

I can certainly change the name of the variable, deprecating ObservedGeneration.

The reason we're using the operator version is because the purpose here is to force a reconcile when the operator is updated.

[rcernich]

Regarding service mesh version, I would expect this to be tracked separately, where users specify the version they want to use (i.e. mesh version would be in the spec, not necessarily the status). Beyond that, I think the operator version is more important, for reasons stated above.

[rcernich]

I've left ObservedGeneration alone and have added a ReconciledVersion field which encompasses the CR generation and the operator's version. This is used to trigger a reconcile when the operator is updated (e.g. version would go from 1.0.0-1 to 1.0.1-1, same generation, 1, but different operator version).

The other commits deal with issues in the Deployment.spec.selector, where the maistra-version label was being included in the selector (the selector field is immutable). The MAISTRA-991 removes the label from places where it shouldn't have been (e.g. in the pod template labels, PodDisruptionBudget selector, etc.), while MAISTRA-992 handles updates where patching won't work (e.g. modifying Deployment.spec.selector).

All of these commits together should enable an automatic update when the operator is updated and should help alleviate issues in future z-stream updates (e.g. 1.0.1 -> 1.0.2).

[knrc]

It looks as if this PR covers three issues, MAISTRA-985, MAISTRA-991 and MAISTRA-992

[knrc]

lgtm, I'll merge it manually