kubeconfig does not reload when changed

[chuckha]

I have a tilt instance up and running with a KUBECONFIG env var set to a valid kubeconfig. I want to reset my cluster and start over from a fresh cluster so I run kubeadm reset and kubeadm init on the node. I then copy down the new /etc/kubernetes/admin.conf kubeconfig and replace KUBECONFIG local file with the contents of the admin.conf file.

Tilt now complains about an x509 error because I have regenerated the CAs which is part of the standard process of kubeadm reset and kubeadm init

I would expect tilt to reload that file and was surprised when I had to kill the process and restart it.

[dbentley]

Ah, thanks. This is good to know.

For context, a lot of how we watch the cluster right now is pretty set at start-up. We don't respond to the context changing at all, and that seems like a good thing.... But.... Hrm. This might not be trivial to fix.

[tclasen]

+1 for this issue. In my ideal world I'd like to be able to execute this Tiltfile:

if config.tilt_subcommand == "down":
    local(command="ctlptl delete -f ./deploy/local-dev-cluster.yaml")
    # Force Exit?
else:
    local(command="ctlptl apply -f ./deploy/local-dev-cluster.yaml")
    # Re-auth or restart tilt with a special flag passed in to skip this step
    # Maybe even just a tilt extension that builds the cluster using ctlptl if it doesn't exist?

for app in ["myapp"]:
    docker_build(app, context="./{}/src".format(app), dockerfile="./{}/deploy/Dockerfile".format(app))
    k8s_yaml("./{}/deploy/k8s.yaml".format(app))

[cam-bond]

Just ran into this, as I was trying to spin up a local cluster using ctlptl by invoking it at the beginning of my tiltfile. The fix was to run ctlptl apply, and then tilt up, but it took a while to figure this out. I was assuming that each k8s_yaml function was loading the kube config when run

[reedjosh]

https://github.com/tilt-dev/tilt/blob/33fc9d7f2fc6b3c18a1af3cc70c39f4b06f7d5ad/internal/k8s/kubeconfig/writer.go#L57

☝️ would it basically be...

1). Find where the above frozen kubeconfig methods are called. 2). Accepting a new configuration variable that allows non-frozen kubeconfigs 3). Based on new config variable either use the frozen kubeconfig or don't?

I really like the idea of starting a tilt file on its own and having it ctlptl me a cluster (or many even).