Comment 2 for bug 1892791

The issue is caused by the fact that the pod spec is not stable - the container name contains a hash of the config. So when a charm sends in a new pod spec and juju updates the k8s Deployment, that triggers a rolling update in which k8s creates a new pod and terminates the old one. Juju will react by deleting the existing unit and adding a new one for the new k8s pod and that new unit becomes leader. It seems this then results in a new pod spec being sent to Juju, and the k8s Deployment is updated because the pod spec has changed (it has the config hash in it) and rinse and repeat.

I stopped the flapping by making the container name stable (removing the config hash). I don't quite fully understand the comment in the charm code as to why the hash is needed. But we need to find a way around it to solve the issue.

Note that the oidc-gatekeeper charm does not have the same issue - the config change triggers an update, and Juju creates a new oidc-gatekeeper/1 unit which becomes leader, and that's how it remains. Making the dex-auth pod spec stable worked the same way.