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

kubectl --local is not quite local across all the commands #93188

Open
soltysh opened this issue Jul 17, 2020 · 7 comments
Open

kubectl --local is not quite local across all the commands #93188

soltysh opened this issue Jul 17, 2020 · 7 comments

Comments

@soltysh
Copy link
Contributor

@soltysh soltysh commented Jul 17, 2020

This situation was discovered when I wanted to remove deprecated functionality in #90243. Unfortunately, due to how we are constructing client in almost every kubectl command this removal ended up with the following bug #90074.

The reason for that is that in each command's Complete method we create a client in one of the following ways:

o.Client, err = batchv1client.NewForConfig(clientConfig)
if err != nil {
	return err
}
dynamicClient, err := f.DynamicClient()
if err != nil {
	return err
}
discoveryClient, err := f.ToDiscoveryClient()
if err != nil {
	return err
}

The problem is that with the deprecated code from #90243 removed all of the above calls will fail when creating a client with:

error: Missing or incomplete configuration info.  Please point to an existing, complete config file:

  1. Via the command-line flag --kubeconfig
  2. Via the KUBECONFIG environment variable
  3. In your home directory as ~/.kube/config

which does not happen if we silently default the server to http://localhost:8080 in deprecated getDefaultServer.

There are two possible approaches to this problem:

  1. Go through each and every single command and add conditions for --local flag and not to create clients when it is specified.
  2. Provide a smart mechanism allowing to inject dependencies (in this particular case, we are talking about clients).

During SIG-CLI call on July 15th, we agreed that solution 1 is a short-term and rather hacky approach to the problem and we would like to see this being approached as described in no. 2.

Any proposals to this should be discussed with @soltysh or during one of sig-cli calls.

@soltysh soltysh added the kind/bug label Jul 17, 2020
@soltysh soltysh self-assigned this Jul 17, 2020
@k8s-ci-robot
Copy link
Contributor

@k8s-ci-robot k8s-ci-robot commented Jul 17, 2020

@soltysh: There are no sig labels on this issue. Please add an appropriate label by using one of the following commands:

  • /sig <group-name>
  • /wg <group-name>
  • /committee <group-name>

Please see the group list for a listing of the SIGs, working groups, and committees available.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@SaiHarshaK
Copy link

@SaiHarshaK SaiHarshaK commented Jul 17, 2020

/assign

@SaiHarshaK
Copy link

@SaiHarshaK SaiHarshaK commented Jul 20, 2020

The sub commands under set, use the flag variable "Local" is instead of "local", shall i rename it's occurrences too?

@SaiHarshaK
Copy link

@SaiHarshaK SaiHarshaK commented Jul 20, 2020

Should i drop the "localhost" check under version_test.go, since we will not default to localhost:8080 anymore?

@SaiHarshaK
Copy link

@SaiHarshaK SaiHarshaK commented Jul 21, 2020

In set_selector.go , i think we hard coded local as false.

@iguoyr
Copy link

@iguoyr iguoyr commented Aug 5, 2020

@soltysh Hi, Can I help with this issue?

I have some questions to above description:

  1. Does --dry-run=client need to have the same strategy as --local?
  2. Is there more detail about the second approache? (my first thought: add --local flag to ClientConfig, if --local is true, catch the ErrEmptyConfig, otherwise, return the error.)
@soltysh
Copy link
Contributor Author

@soltysh soltysh commented Aug 26, 2020

@iguoyr feel free to leave your proposals here, I'd like to have a discussion about possibilities within this issue before we decide how to solve it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

4 participants
You can’t perform that action at this time.