Context
The sensitive data needed for ExternalDNS instances is propagated as Kubernetes secrets. These secrets are consumed in different ways: as environment variables (aws, infoblox) or as volume mounts (azure, gcp, bluecat).

The problem arises when the sensitive data is updated by the customer after it was consumed by the ExternalDNS instance for the first time.
Kubernetes would update the secret's content consumed as volumemounts but not the content of environment variables.
So the ExternalDNS instances created for the providers which consume the sensitive data as environment variables would have to be restarted (at least the containers).
Unfortunately the ExternalDNS instances created for the providers with the volumeMount consumption are having the same problem because the ExternalDNS reads the configuration file contents only at the start.

Goal
The goal of this user story is to implement a mechanism which would force the ExternalDNS containers to re-read the updated contents of the consumed secret.
One of the possible implementations would be the update of the operand's deployment resource with the checksum of the secret's contents. This would trigger a new deployment in case the secret contents changed which in turn would restart the containers forcing them to re-read the updated contents. The checksum can be stored as an annotation.

Acceptance Criteria

• Code and unit test updated