Env. variable is not updated after user sets an invalid PodTemplateSpec value

[jsenko]

Field spec.deployment.podTemplateSpecPreview in the ApicurioRegistry CR provides users with a powerful way to configure the resulting Apicurio Registry Deployment resource. However, the Operator does not check whether the field is valid. If, for example, user configures a volume mount when the corresponding volume does not exist, this change is rejected when the Operator attempts to apply it to the cluster. This might result in a partial reconcilliation of the Apicurio Registry Deployment resource, or the Operator crashing. In one case, even after the invalid PodTemplateSpec value was corrected, the Operator failed to update value of an env. variable after it has been changed by an user in the spec.configuration.env field.

In case you encounter this issue, and you'll see an error in the Operator logs similar to:

msg="Could not create new resource." resource=apps.Deployment error="Deployment.apps \"example-deployment\" is invalid: [...]"

or

msg="could not submit patch" resource=apps.Deployment error="Deployment.apps \"example-deployment\" is invalid: [...]"

correct the invalid value in the spec.deployment.podTemplateSpecPreview field, and then delete the Deployment resource to allow the Operator to recreate it. This should resolve further issues.

[pwright]

@jsenko if i change spec.deployment.podTemplateSpecPreview but also some other value, eg spec.configuration.keycloak.url, is only the pod config affected, or is the whole CR rejected?

[jsenko]

The CR is not rejected and will be updated, because it's still syntactically valid, but the Operator would not be able to act on the change and update the Deployment. So the change to the keycloak URL field will likely not have any effect (until the recovery steps are done). So in the end there might be partial reconcilliation, where only some of the configuration defined by the CR is translated to the Deployment.