Allow default kubeconfig resolution #62
Conversation
- Changed the default kubeconfig loading to utilize the client-go's loader strategy. This allows users to use the Ark client without having to explicitly define a KUBECONFIG env var or argument. This more closely resemebles how Kubectl works and users are probably more used to while preserving the current rules. Signed-off-by: Justin Nauman <justin.r.nauman@gmail.com>
|
Can one of the admins verify this patch? |
|
ok to test |
| return clientcmd.BuildConfigFromFlags("", kubeconfig) | ||
| loader := clientcmd.NewDefaultClientConfigLoadingRules() | ||
| loader.ExplicitPath = kubeconfig | ||
| clientConfig, err := clientcmd.BuildConfigFromKubeconfigGetter("", loader.Load) |
There was a problem hiding this comment.
There are very few places in the kube code base that use BuildConfigFromKubeconfigGetter. It might be better to match more closely what's in https://github.com/kubernetes/kubernetes/blob/775f5d232d21eccc967a2007e5290f04ef15d93b/pkg/kubectl/cmd/util/factory_client_access.go#L156-L174, but changing it up a bit:
return clientcmd.NewNonInteractiveDeferredLoadingClientConfig(loader, nil), nilWe may want to have that nil be actual overrides.
There was a problem hiding this comment.
That can work as well. Is your concern that since it's not used much the behavior may change over time in an unanticipated way and that we are reliant upon the implementation details?
There was a problem hiding this comment.
It was more that "kubectl does it a different way" 😄 . The kube client config loading code is difficult for me to keep all of it in my head at the same time... I did test your branch locally to confirm that it still loaded the in-cluster config (when running as a pod), and that did work. The more that I think about it, I'm fine with this.
There was a problem hiding this comment.
Sounds good. I dug in a bit deeper to the code sample you gave and the main things I think differ are around the overrides that you mentioned. If we go with this for now and our needs change, we can certainly just shift to a more explicit resolution process as your code sample gives.
I agree that it's a lot to grok and I was surprised there wasn't something a bit more "direct" in the client package that others could just use to keep ti consistent
the client-go's loader strategy. This allows users
to use the Ark client without having to explicitly
define a KUBECONFIG env var or argument.
This more closely resemebles how Kubectl works and users
are probably more used to while preserving the
current rules.
Signed-off-by: Justin Nauman justin.r.nauman@gmail.com