Comment 5 for bug 1892791

I believe it *could* but if that isn't how the application container was written, then it doesn't actually do that.
It seems odd for the application to be written to consume from a ConfigMap but not actually watch the content of the ConfigMap (I've seen some cases where they expect something like SIGHUP as the way to reread from the filesystem).

Having a stable hash for the container is also a possibility. The juju config itself isn't changing, presumably it is other content that is ending up in the config hash. But is this IP addresses or unit names, or something else that we should be avoiding since it isn't stable?

Looking here:
https://github.com/juju-solutions/bundle-kubeflow/blob/master/charms/dex-auth/reactive/dex_auth.py#L77

a) 'static-config' uses uuid4() which means that every time it is evaluated it changes (so not very static)
If you do need a newly generated but not changing on every hook invocation uuid, then you would want to put that into either leader data, or into a peer relation for the application.
b) I don't know what is in oidc_client_info but that looks to be data that was from a relation, so it shouldn't be changing on a new unit

So it seems that it is just that your userID is dynamically generated each pass through this function, which causes it to get a new config hash. If you change how the user id is generated then the config should be stable and you should be able to append the config hash.