Skip to content

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

Merged
landism merged 3 commits into
masterfrom
matt/allow_k8s_contexts
Aug 8, 2019
Merged

unrevert "tiltfile: disallow deploys to remote kube by default"#2012
landism merged 3 commits into
masterfrom
matt/allow_k8s_contexts

Conversation

@landism

@landism landism commented Aug 7, 2019

Copy link
Copy Markdown
Member

(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 jazzdan and nicks August 7, 2019 21:50

@jazzdan jazzdan left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

LGTM!

@nicks nicks left a comment

Copy link
Copy Markdown
Contributor

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.

Comment thread internal/tiltfile/tiltfile_state.go Outdated
// 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
Copy Markdown
Contributor

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
Copy Markdown
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
Copy Markdown
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

@nicks nicks left a comment

Copy link
Copy Markdown
Contributor

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