-
Notifications
You must be signed in to change notification settings - Fork 96
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
Consider supporting connectionSecretDeletionPolicy
#269
Comments
Is there any chance we could get away with just lumping this in with the existing |
@negz possibly, if a user wanted the connection secret cleaned up after |
Definitely worth considering. I don't feel strongly here - just looking for places to keep our API a little simpler. I like the idea of being able to handle this simply (i.e. by orphaning secrets) now, while leaving an avenue over to control that behaviour in future. |
Reusing |
Facing this issue with provider-sql here. When a resource such as a MySQL user or PostgreSQL role is deleted with It'd be really nice if |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
What problem are you facing?
Currently, managed resources support setting
deletionPolicy
in thespec
to eitherDelete
(default) orOrphan
. This allows users to remove a managed resource from the Kubernetes API without it being deleted externally. However, when a managed resource is deleted withdeletionPolicy: Orphan
, its connectionSecret
is still cleaned up in the cluster. This makes sense in most cases (similar to how it usually makes sense to delete the infrastructure externally when the managed resource is deleted), but it does make it inconvenient to migrate resources from one cluster to another while preserving all connection details. Some external APIs only return full connection details when the resource is initially created, so later "importing" an existing external resource into the cluster will not provide the full connection information.How could Crossplane help solve your problem?
Introducing a common
connectionSecretDeletionPolicy
(or nesting adeletionPolicy
underwriteConnectionSecretToRef
/publishConnectionDetails
) to all managed resources will make this behavior configurable. By default, the policy should beDelete
, but some cases, such as those listed above would be candidates for usingOrphan
. I imagine this functionality will become even more useful once additionalSecret
"sinks" are supported, as described in crossplane/crossplane#2366.The text was updated successfully, but these errors were encountered: