`talosctl cluster destroy [cluster name]` not updating talosctl config file
nicholas-fedor opened this issue · comments
Bug Report
Description
Follow the guides for setting up a local cluster using Docker:
https://www.talos.dev/v1.7/introduction/quickstart/
https://www.talos.dev/v1.7/talos-guides/install/local-platforms/docker/#cleaning-up
talosctl cluster destroy cluster2 does not remove cluster2 from ~/.talos/config and leaves cluster2 as the global context.
talosctl config remove cluster2 is needed in order to remove the cluster from talosctl's config and update the context.
Environment
- Talos version: v1.7.4
- Kubernetes version: v1.30.2
- Docker version: v26.1.4
- Platform: Ubuntu 24.04
This extends to both the clusters and contexts portions of the kubectl config.
FWIW I don't think that automatically removing cluster data by default from talosconfig is a good idea. We could add a flag that will do it, but most of the time you want to preserve the info held there. Just in case something goes wrong.
I agree with your points on this.
I suppose there's the potential for a future feature, such as within talosctl reset, to clean/reset the host being used to run talosctl and kubectl.
With respect to the guide/documentation referenced (and why I put this down as a bug report), it might be worth adding some brief instructions regarding the handling of contexts and the configuration. This is particularly apropos for when managing multiple Docker-based dev clusters. Context management isn't something that is immediately apparent to less-experienced users, who might follow the guide, create multiple clusters, and then run into the challenge navigating multiple contexts. There is mention of the context flag, but no mention of setting the current context.
Two examples of updated guides. I'm not 100% set on these and will likely write a fresh walkthrough for setting up and managing Docker-based clusters.
Quickstart
Local Platforms/Docker/Cleaning Up
Would it be reasonable for the current-context to be automatically changed to either the next available or a blank context when the existing current-context is deleted via talosctl config remove?
The problem is that when the cluster is being removed, there is no way to match it against your cluster config exactly, so we have no way to do automatic clean up, and given that talosconfig and kubeconfig might contain your production cluster configs, keeping configs is more safe than trying to remove it. It might have been nice if the dev cluster PKI was stored separately, but not in the current design.
But we would take PRs for the documentation updates you link to above!