Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upkubectl --local is not quite local across all the commands #93188
Comments
@soltysh: There are no sig labels on this issue. Please add an appropriate label by using one of the following commands:
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. |
/assign |
The sub commands under set, use the flag variable "Local" is instead of "local", shall i rename it's occurrences too? |
Should i drop the "localhost" check under version_test.go, since we will not default to localhost:8080 anymore? |
In set_selector.go , i think we hard coded local as false. |
@soltysh Hi, Can I help with this issue? I have some questions to above description:
|
@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. |
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:The problem is that with the deprecated code from #90243 removed all of the above calls will fail when creating a client with:
which does not happen if we silently default the server to
http://localhost:8080
in deprecatedgetDefaultServer
.There are two possible approaches to this problem:
--local
flag and not to create clients when it is specified.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.