KUDO 0.10.0 does not perform rolling update if ConfigMap changes

[ANeumann82]

What happened:
When updating an operator with a specific param that updates only a ConfigMap, the StatefulSet that references this ConfigMap does not get restarted.

What you expected to happen:
The StatefulSet referencing the updated ConfigMap should perform a rollingUpdate

How to reproduce it (as minimally and precisely as possible):

• Have an operator with a configMap and a stateful set. Let the StatefulSet use the ConfigMap.
• Deploy the operator
• Run `kudo update --instance -p <PARAM_IN_CONFIGMAP>=SomeNewValue
• The ConfigMap is updated, but the StatefulSet does not restart.

Anything else we need to know?:
From what I figured out, this is an issue from removing Kustomize to render templates and enhance them with metadata (labels and annotations):

Before the update, Kustomize would add annotations and labels to the rendered statefulset, including the statefulset.spec.template.metadata. As this is a change to the spec in the StatefulSet, it would trigger a restart of the STS.

With the new code, we only set the metadata on the statefulSet itself, not on the template for the Pods, and therefore we don't trigger the restart anymore.

Environment:

• Kudo version (use kubectl kudo version): 0.10.0

[ANeumann82]

Related to #1303

[alenkacz]

oh, good catch! :) so maybe we removed kustomize prematurely after all? We should really test this functionality...

[ANeumann82]

Well, removing kustomize is fine, I think, we just need to apply the metadata recursivly, the same as kustomize did.

[alenkacz]

@ANeumann82 I wonder if we're not reimplementing kustomize then... depends on how complex looking for those places recursively is. I guess it's still better than kustomize as dep :)

[ANeumann82]

@alenkacz I've created a PR that applies the metadata recursively, it's not too much code.