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

Secret ownerReferences not restored #6979

Closed
killianmuldoon opened this issue Jul 26, 2022 · 6 comments
Closed

Secret ownerReferences not restored #6979

killianmuldoon opened this issue Jul 26, 2022 · 6 comments
Assignees
Labels
kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt.

Comments

@killianmuldoon
Copy link
Contributor

When Cluster API is backed up and restored the ownerReferences on the Kubernetes Secrets relating to the cluster are not restored. This doesn't seem to cause issues in the functioning of the cluster, but it causes these Secrets to not be deleted when the Cluster is deleted.

The following flow then results in an error as some of the secrets continue to exist unexpectedly.

  1. Restore cluster 'my-cluster' from backup
  2. Delete cluster 'my-cluster'
  3. Create a new cluster called 'my-cluster'

There is no reconciler that watches Secrets in CAPI, so there's no obvious place to restore the references. Some options for improving this situation:

  1. Document that kubectl delete secrets -l cluster.x-k8s.io/cluster-name=cloister (or similar) should be run as part of cleaning up a Cluster API cluster.
  2. Add a cleanup step in CAPI to add ownerReferences to a Cluster, where it exists, based on the cluster name and namespace.
  3. Add a cleanup step, external or in the reconciler, to delete secrets that are not being used by any existing CAPI objects.

/kind cleanup
/area ux

May be related to other orphaned object cleanups e.g.
#6863

@k8s-ci-robot k8s-ci-robot added kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. area/ux labels Jul 26, 2022
@fabriziopandini fabriziopandini added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed triage/accepted Indicates an issue or PR is ready to be actively worked on. labels Jul 29, 2022
@sbueringer
Copy link
Member

sbueringer commented Aug 16, 2022

Is this related (only) to the KCP secrets?

Naively I would have assumed that when we create Secrets with ownerRefs we should also adopt them after restore (~ at the same place in the code).

@killianmuldoon
Copy link
Contributor Author

I think this is the relevant code for kubeadmconfig:

certificates := secret.NewCertificatesForInitialControlPlane(scope.Config.Spec.ClusterConfiguration)

In this function we only set the owner references on generating the secrets, if the secrets exist and has a correctly formatted KeyPair we don't re-add the owner references.

@sbueringer
Copy link
Member

Could be a good place to "adopt" if the ownerRefs of the current secrets are missing (not sure what is executed after the initial create)

@killianmuldoon
Copy link
Contributor Author

/assign

@killianmuldoon
Copy link
Contributor Author

/close

Fixed by #7587 and #7592

@k8s-ci-robot
Copy link
Contributor

@killianmuldoon: Closing this issue.

In response to this:

/close

Fixed by #7587 and #7592

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt.
Projects
None yet
Development

No branches or pull requests

4 participants