Idempotent creationPolicy option that tries to 'Merge' but reverts to 'Owner' #3413
Labels
kind/feature
Categorizes issue or PR as related to a new feature.
triage/needs-information
Indicates an issue needs more information in order to work on it.
Is your feature request related to a problem? Please describe.
Currently if I am determining a strategy to propagate a secret that is common to many namespaces on a Kubernetes cluster after the cluster has been bootstrapped. Due to the nature of ESO creation policies, if I need to deploy my registry credentials into a handful of namespaces, I can't create a ExternalClusterSecret that will create the secret if it doesn't exist in the namespace, or instead merge the secret contents into an existing secret. So I could define 2 external cluster secrets with different creation policies, but why not have a creation policy that is more or less idempotent - make sure the secret exists one way or the other - and try if anything to update relevant keys (ie merge) when there is a secret.
Describe the solution you'd like
a creation policy that is more or less idempotent - make sure the secret exists one way or the other - and try if anything to update relevant keys (ie merge) when there is a secret.
ie if the secret exists, apply the merge creationpolicy. if the secret does not exist create the secret.
Describe alternatives you've considered
I could define 2 external cluster secrets with different creation policies, depending on whether or not the secret should exist in a bootstrapping/day2 provisioning scenario
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: