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

unrevert "tiltfile: disallow deploys to remote kube by default" #2012

Merged
merged 3 commits into from
Aug 8, 2019

Conversation

landism
Copy link
Member

@landism landism commented Aug 7, 2019

(re-)resolves #1096

#1995 was reverted because it turns out the latest Docker for Desktop doesn't use "localhost" as its kube api, but instead adds kubernetes.docker.local to /etc/hosts, and uses that.

This is a two-commit PR:
#1 Revert the revert (i.e., exactly what was already approved)
#2 Add Docker for Desktop context names to the whitelist

@landism landism requested review from nicks and jazzdan August 7, 2019 21:50
Copy link
Contributor

@jazzdan jazzdan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Copy link
Member

@nicks nicks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i wonder if we should expose this via tilt doctor

my main concern is having multiple codepaths that each invent their own definition of "local" cluster.

// These are k8s context names that we assume are safe to deploy to even if they are neither localhost
// nor in allow_k8s_contexts. e.g., minikube uses a non-loopback ip on a virtual interface,
// and some versions of docker-for-desktop use 'kubernetes.docker.local'
var defaultWhitelistedKubeContexts = []k8s.KubeContext{"minikube", "docker-desktop", "docker-for-desktop"}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can this use the Env constants?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my main concern is having multiple codepaths that each invent their own definition of "local" cluster.

I'd forgotten about Env when writing this. Do you see any downside to just using Env.IsLocalCluster and skip checking the url?

I'm not very familiar with KIND, but it seems like the chief current use of Env.IsLocalCluster is to check whether can skip the push to docker, and we push to docker for KIND even though it's local? Which is to say, I'm not sure whether this method's goals align with the safety check's. Either way, though, it seems like it makes sense to put this logic in env.go.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, new take:

  1. renamed the existing Env.IsLocalCluster to Env.UsesLocalDockerRegistry, since that seems to better match its existing use, and then made a new Env.IsLocalCluster that also includes KinD.
  2. just use Env.IsLocalCluster and don't get clever in the tiltfile code

Copy link
Member

@nicks nicks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ya, that seems fine too

@landism landism merged commit a71eb47 into master Aug 8, 2019
@landism landism deleted the matt/allow_k8s_contexts branch August 8, 2019 16:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Should Tilt allow deploys to non-local kubecontexts by default?
3 participants