Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idempotent creationPolicy option that tries to 'Merge' but reverts to 'Owner' #3413

Open
charles-horel-rogers opened this issue Apr 24, 2024 · 1 comment
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.

Comments

@charles-horel-rogers
Copy link

charles-horel-rogers commented Apr 24, 2024

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.

@charles-horel-rogers charles-horel-rogers added the kind/feature Categorizes issue or PR as related to a new feature. label Apr 24, 2024
@charles-horel-rogers charles-horel-rogers changed the title creationPolicy option that tries to 'Merge' but reverts to 'Owner' Idempotent creationPolicy option that tries to 'Merge' but reverts to 'Owner' Apr 24, 2024
@gusfcarvalho
Copy link
Member

gusfcarvalho commented May 1, 2024

Hi @charles-horel-rogers ! The problem with the revert behavior you're mentioning is that CreationPolicy: Owner means as soon as the ExternalSecret manifest is deleted, the secret is also deleted. This is not true for CreationPolicy: Merge (where only some keys of that secret are cleaned up). This behavorial difference means this is cannot be held together in the same idempotency bucket (it could delete previously existing secrets)

To your point in question - have you tried CreationPolicy: Orphan? I believe it will have the outcomes as you'd wish.

@gusfcarvalho gusfcarvalho added the triage/needs-information Indicates an issue needs more information in order to work on it. label May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.
Projects
None yet
Development

No branches or pull requests

2 participants