Update existing resources when CR changes

[rm3l]

Update existing resources when CR changes

[rm3l]

Notes from last meeting:

• before the first version of the Operator is released, we need to support the case where Backstage Config is changed (but not CR), as this is a common use case to update an app-config ConfigMap. We should document that the user needs to restart the Backstage pod in case of a config change (until #74 is implemented).
  We also need to support the case where CR itself is updated (scope of this issue). This is part of the user workflow: installing RHDH, then updating CR to include their app-config files, dynamic plugins config and/or env vars..

[gazarenkov]

@rm3l
I probably missed that (being on PTO)

we need to support the case where Backstage Config is changed (but not CR)

Not sure I understand terminology here but I suppose it means changes in app-config's (and extra) ConfigMaps etc, right?

I think we need carefully investigate the cases and understand and document limitations.
For example, as I understand https://kubernetes.io/docs/concepts/configuration/configmap/#mounted-configmaps-are-updated-automatically it says it will be refreshed, but not for env variables and "A container using a ConfigMap as a subPath volume mount will not receive ConfigMap updates."

I would like we investigate, understand and document these limitations (what is supported by K8s and what we need to take care in the Operator) before we make a decision about making it supported user-friendly way.

Meanwhile, I agree, we need to mention that all the configuration changes "guaranteed" only after Backstage resource reconciliation (pod deleting or down/up scaling of replicas would be sufficient I guess)

[rm3l]

@rm3l I probably missed that (being on PTO)

we need to support the case where Backstage Config is changed (but not CR)

Not sure I understand terminology here but I suppose it means changes in app-config's (and extra) ConfigMaps etc, right?

Yes, that's the (quite common) use case Tomas mentioned: making changes to app-config should be handled by the operator.

I think we need carefully investigate the cases and understand and document limitations. For example, as I understand kubernetes.io/docs/concepts/configuration/configmap/#mounted-configmaps-are-updated-automatically it says it will be refreshed, but not for env variables and "A container using a ConfigMap as a subPath volume mount will not receive ConfigMap updates."

I would like we investigate, understand and document these limitations (what is supported by K8s and what we need to take care in the Operator) before we make a decision about making it supported user-friendly way.

Meanwhile, I agree, we need to mention that all the configuration changes "guaranteed" only after Backstage resource reconciliation (pod deleting or down/up scaling of replicas would be sufficient I guess)

Indeed, Tomas said that we are not sure Backstage would be able to hot-reload itself upon configuration changes; so we would need to restart Backstage even if K8s automatically refreshes the mounted files.

I agree we need to investigate. #74 includes a research part to evaluate this. That's why we broke down the parent Epic (#12) into two cases (updates to the CR itself vs updates to resources linked to the CR).
For now, we'll document how to "restart" the Backstage resources upon configuration changes (that's what I documented in #118 - deleting the Backstage Deployment makes the operator recreate it with the updated information).