Current implementation will break independent application lifecycle

[juliohm1978]

Configurator's current implementation relies on keeping tabs about which ConfigMap (CM) holds the latest data from its owner CustomConfigMap (CCM).

In order to use CMs managed by Configurator, an independent application needs to wait for a managed CM to be created, which includes a random suffix on its name. This CM with a strangely suffixed name needs to be used by the application in its first initial setup. After being deployed, Configurator will patch the Deploy/Sts of an independent application, changing the name of the CM that was initially used.

This behavior can certainly break the lifecycle of the application using the CM. In fact, the application needs to be aware of the first CM name, and that needs to become part of its initial setup. Most applications, specially ones managed by a GitOps tool like FluxCD or ArgoCD, can interfere with patched resources and bring the CM reference back to its original name (the one the app was originally deployed with).

I think the current implementation that relies on random CM names being patched in Deploy/Sts objects will not prevail by intefereing with a broader application lifecycle. There must be a presumption that CM names are controlled by an independent application, and those names need to be kept as they were intiially deployed, so that applications do not get entangled with the behavior that Configurator provides.

[juliohm1978]

Dropping by to attach a proposal for a new workflow.

Rearchitecture_Proposal.html.zip

Fully open for discussion and improvements.

[juliohm1978]

This is an updated version, with a diagram.

Configurator_-_Rearchitecture_Proposal.pdf

[gopaddle-io]

Fixed in revision 0.0.2