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

remove #2325

Closed
ghost opened this issue Jun 24, 2019 · 10 comments
Closed

remove #2325

ghost opened this issue Jun 24, 2019 · 10 comments

Comments

@ghost
Copy link

ghost commented Jun 24, 2019

"The wages of sin are death; but after they're done taking out taxes, it's just a tired feeling:"

@seblegall
Copy link
Contributor

seblegall commented Jun 24, 2019

Why would you like to specify both a kubectl config file and un context?

In my understanding, kubectl config file may be managed with 2 strategy :

  • One big config file with multiple context and a default context set
  • One config file for each context

The ability to specify a file (where a default context is set) should be enough, right?

@seblegall
Copy link
Contributor

@braderhart I see. It seems to me that the use case of having multiple config files and multiple context in each is a little bit particular.

Maybe we could start by taking in consideration a specified config file as a first step and see later if there is a need for specifying a context.

Then, you've suggested to add this feature in the configuration file skaffold.yml. But kube config files and contexts can be named differently depending of the developer configuration. And since the skaffold.yml file is supposed to be versioned with your project, how would you do for different people working on the same team, on the same project but using different config for their local kubectl?

In my point of view, the kube config file (or the context) is something that vary depending on the user running skaffold, not depending on the project built with skaffold.

In this case, don't you think it should be a CLI flag?

@balopat
Copy link
Contributor

balopat commented Aug 16, 2019

Hi @braderhart - do you mind writing this up as a design proposal? It sounds like a larger effort that needs some thought.

@tejal29
Copy link
Contributor

tejal29 commented Aug 21, 2019

@corneliusweig I remember your design proposal #2384 addresses this?

@corneliusweig
Copy link
Contributor

Hey @tejal29, thanks for highlighting this for me.

So to summarize the ideas listed here:

  1. add CLI option to configure the kube-context
  2. add CLI option to configure the kubeconfig file
  3. add Skaffold config option to configure the kube-context per project
  4. add Skaffold config option to configure the default profile per project
  5. add skaffold.yaml config to configure the kube-context
  6. add skaffold.yaml config to configure the kubeconfig file

@seblegall @braderhart Please let me know if I missed something.


Out of those items, 1), 3) and 5) are addressed by design proposal #2384. It's also implemented, though not merged yet.

@braderhart @seblegall You are encouraged to take a look at this and let me know if this is sufficient for your use-cases.


As to 2) and 6), I'm totally with @seblegall:

In my point of view, the kube config file (or the context) is something that vary depending on the user running skaffold, not depending on the project built with skaffold.

I think it does not make sense to configure a kube-config file in skaffold.yaml, as the file location varies too wildly for different users. We even had the same discussion for kubecontext which has the same issue but for the config file location it's even worse.

Also, I'm currently -1 for adding another CLI flag for the kubeconfig location. Skaffold already has a lot of CLI options, including 2 flags for configs (skaffold.yaml + skaffold config). Adding a third config file flag will cause massive confusion. Besides, the KUBECONFIG env variable should already be fully supported (can you confirm that @braderhart?).


As to item 4) "configure a default profile for a given Skaffold project"

I think it's worth investigating. At the moment, I don't fully understand the use-case, though. In essence, this config permanently changes the main profile to a given profile (in particular, the main profile won't be accessible anymore). However, this effect can be attained in a much cleaner way by restructuring the skaffold.yaml file, so that the default profile configuration is applied to the main profile.

Do you agree @braderhart?

@woodcockjosh
Copy link

Just accidentally wiped out my shared dev environment with skaffold because I forgot to update the kube context. Would love this feature to be completed soon.

@corneliusweig
Copy link
Contributor

@woodcockjosh I presume you are referring to the context via skaffold.yaml or global config feature?

@woodcockjosh
Copy link

woodcockjosh commented Sep 11, 2019

@corneliusweig I'm referring to the kube context. eg kube config use-context mycontext

@balopat balopat added priority/p0 Highest priority. We are actively looking at delivering it. and removed needs-design-proposal labels Sep 20, 2019
@balopat
Copy link
Contributor

balopat commented Sep 20, 2019

Kubecontext can be passed already as a command line flag.
Setting kubecontext in skaffold.yaml is being worked on and soon will be merged. Follow #2510 for updates.
For kubeconfig you can follow #2699.

@tejal29 tejal29 added priority/p1 High impact feature/bug. and removed priority/p0 Highest priority. We are actively looking at delivering it. labels Sep 23, 2019
@balopat
Copy link
Contributor

balopat commented Nov 15, 2019

This should doable now in the next release (v1.1.0 that will come next week) or the bleeding edge https://skaffold.dev/docs/install/, please open an issue if you run into a problem

@balopat balopat closed this as completed Nov 15, 2019
@ghost ghost changed the title Support kube.config and kube.context for specifying alternative Kubernetes config file or context remove May 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants