-
Notifications
You must be signed in to change notification settings - Fork 40k
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
Check for EmptyConfig errors when trying to use in-cluster config #31947
Check for EmptyConfig errors when trying to use in-cluster config #31947
Conversation
Note the controller and scheduler were not affected because they don't use a DeferredNonInteractiveConfig. Kubectl was not affected because it uses a Deferred*Config with defaulting. OpenShift would not have been broken since we use a wrapper (which basically was there to fix this particular bug). |
I don't think this needs a release note because the issue never actually manifested in any code (kube-dns was not built). |
@deads2k can you review? |
@@ -358,21 +358,21 @@ func (inClusterClientConfig) ClientConfig() (*restclient.Config, error) { | |||
return restclient.InClusterConfig() | |||
} | |||
|
|||
func (inClusterClientConfig) Namespace() (string, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this function never actually returns an error. Remove the error parameter or use it instead of the bool.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this function never actually returns an error. Remove the error parameter or use it instead of the bool.
It's implementing an interface. Other implementors do return errors.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add a couple type assertions. this dropped out of the ClientConfig
interface at some point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's part of an interface, then change the interface, too-- (string, bool, error) is a confusing return set.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The interface is correct - this implementation just happens not to return an error. The bool is "was this specified" by the user. The string is the value. We use the bool all over the code to determine between user passed "--namespace" on the CLI vs getting the "default" namespace.
I still can't understand this loader code. lgtm but maybe @jlowdermilk wants to take a look? |
return icc.ClientConfig() | ||
|
||
// check for in-cluster configuration and use it | ||
if config.icc.Possible() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is going to have priority, why don't we do it first?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hrm, I see. It doesn't have priority. And it can't go into the switch above because of the error handling down the non-nil patch. What sticky little bit of code.
@deads2k any other comments? |
@smarterclayton no more comments from me. lgtm, could use a squash. |
By removing the default "localhost:8080" behavior several paths in client config began returning err == ErrEmptyConfig rather than err == nil. The code checking for in cluster config was wrong - the logic should be: 1. If loading the underlying config returns a non-empty error, fail 2. If the underlying config is not equal to the default config, return that config (it's got user input) 3. If it is possible to use in cluster config, do so 4. Otherwise return the default config (and or default EmptyConfig error).
de7e1c7
to
48b4d6d
Compare
GCE e2e build/test passed for commit 48b4d6d. |
Squashed |
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
GCE e2e build/test passed for commit 48b4d6d. |
Automatic merge from submit-queue |
Changes made in kubernetes#31947 cause kube-proxy to ignore `--kubeconfig` and `--master` flags and use in-cluster configuration, which is unusable due to the fact that VIP hasn't been created yet.
Changes made in kubernetes#31947 cause kube-proxy to ignore `--kubeconfig` and `--master` flags and use in-cluster configuration, which is unusable due to the fact that VIP hasn't been created yet.
Automatic merge from submit-queue Automated cherry pick of #31947 By removing the default "localhost:8080" behavior several paths in client config began returning err == ErrEmptyConfig rather than err == nil. The code checking for in cluster config was wrong - the logic should be: 1. If loading the underlying config returns a non-empty error, fail 2. If the underlying config is not equal to the default config, return that config (it's got user input) 3. If it is possible to use in cluster config, do so 4. Otherwise return the default config (and or default EmptyConfig error). Cherry-pick of #31947
removing cherrypick-candidate as this was previously merged in release-1.4 |
Changes made in kubernetes#31947 cause kube-proxy to ignore `--kubeconfig` and `--master` flags and use in-cluster configuration, which is unusable due to the fact that VIP hasn't been created yet.
Check if default config is invalid before comparing it Changes made in kubernetes#31947 cause kube-proxy to ignore `--kubeconfig` and `--master` flags and use in-cluster configuration, which is unusable due to the fact that VIP hasn't been created yet.
Check if default config is invalid before comparing it Changes made in kubernetes#31947 cause kube-proxy to ignore `--kubeconfig` and `--master` flags and use in-cluster configuration, which is unusable due to the fact that VIP hasn't been created yet.
…-of-#31794-kubernetes#32165-kubernetes#31655-kubernetes#31833-kubernetes#31947-kubernetes#30105-upstream-release-1.4 Automated cherry pick of kubernetes#31794 kubernetes#32165 kubernetes#31655 kubernetes#31833 kubernetes#31947 kubernetes#30105
…-of-#31947-kubernetes#32072-kubernetes#32105-kubernetes#32197-kubernetes#32181-upstream-release-1.4 Automated cherry pick of kubernetes#31947 kubernetes#32072 kubernetes#32105 kubernetes#32197 kubernetes#32181
…onfig_14 Automatic merge from submit-queue Automated cherry pick of kubernetes#31947 By removing the default "localhost:8080" behavior several paths in client config began returning err == ErrEmptyConfig rather than err == nil. The code checking for in cluster config was wrong - the logic should be: 1. If loading the underlying config returns a non-empty error, fail 2. If the underlying config is not equal to the default config, return that config (it's got user input) 3. If it is possible to use in cluster config, do so 4. Otherwise return the default config (and or default EmptyConfig error). Cherry-pick of kubernetes#31947
By removing the default "localhost:8080" behavior several paths in
client config began returning err == ErrEmptyConfig rather than err ==
nil. The code checking for in cluster config was wrong - the logic
should be:
return that config (it has user input)
error).
Fixes #31910 @thockin @lavalamp @deads2k. We introduced EmptyConfig a very long time ago, but until I removed the "localhost:8080" Kubernetes was not actually exposing it (OpenShift relies on it since we don't set an insecure default). This properly falls through to in-cluster config in the described conditions.
This change is