-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Adds ability to use kubeconfig context #351
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
Conversation
- adds --context parameter to operator-sdk command - adds KUBERNETES_CONTEXT env var - adds buildConfigWithContext to client.go - fixes some error handling
@pawelprazak Sorry for the delay in reviewing this. Can you explain what happens if we omit the context flag?
Would that result in the current behavior of just using the |
It uses the current context, at least that's how I've tested it. I have multiple clusters in my If the param is omitted it will pass an empty current context to the k8s client: |
@pawelprazak the pr looks good in general. But I want to see some manual tests. |
It never worked for me without the context. |
@pawelprazak |
my current context is empty by default
…On Fri, Aug 3, 2018, 18:49 Fanmin Shi ***@***.***> wrote:
@pawelprazak <https://github.com/pawelprazak> It never worked for me
without the context.
Hmm, something not right. I expect that operator-sdk up local works with
default behavior which uses the $HOME/.kube/config and the current
context. Also i expect that the operator-sdk up local
--kubeconfig=$HOME/.kube/config defaults to use the current context.
Could you investigate why is it failing?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#351 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAC-6ih8BAfM5jWt415AYrquPSJx0dZZks5uNH8BgaJpZM4VXtyl>
.
|
Is |
About wrong behaviour: it is well known that invalid mengo library versions lead to contexts being dropped. Please double check that the used mengo revision is exactly the one required by the used client-go's |
@pawelprazak could you test out the test scenarios with a default current context? |
@sttts AFAIK |
@fanminshi how do I do that, what should be the content of |
@pawelprazak can we discuss introducing that context var in clientcmd instead of here? If we add that for operator-sdk we create a incompatible, inconsistent kubeconfig semantics in the ecosystem. |
@sttts not sure what do you mean by |
The new function was rejected because the override mechanism already supports context overrides. I don't know about the KUBERNETES_CONTEXT discussion. |
Is this a client command that is trying to be consistent with consuming a kubeconfig? If so, it seems like you'd want something like https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/genericclioptions/config_flags.go . |
@pawelprazak I believe the command also it seems like @sttts have a different opinion on add this new change. Let's discuss more before we move forward. |
Actually, I think, #169 might solve the root of the problem that I was trying to solve. I don't actually need the CLI to be extended, since I use a custom Makefile instead of it, I've implemented it in this PR for completeness. |
return config, err | ||
} | ||
|
||
// see clientcmd.BuildConfigFromFlags() | ||
func buildConfigWithContext(kubeconfigPath string, context string) (*rest.Config, 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.
FYI: this is the most important change that allows me to implement what I need, the rest is just supporting it
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.
from the looks of it, decorating GetConfig
function https://github.com/kubernetes-sigs/controller-runtime/blob/master/pkg/client/config/config.go#L59 should give me the same result (after controller-runtime refactoring is merged)
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.
I agree with @deads2k 's comment. Any chance you could use https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/genericclioptions/config_flags.go here? (Example usage: https://github.com/kubernetes/sample-cli-plugin/blob/master/pkg/cmd/ns.go)
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.
sorry, the first link gives me 404
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.
sorry, the first link gives me 404
@pawelprazak With the SDK
And use that context to build your kubeconfig and pass it to your reconciler's client. This way the SDK probably doesn't need to introduce new CLI changes or env vars. |
Thank you, that's what I had in mind. Closing now. |
Add support for multi-cluster use cases like
kubectl
does.--context
parameter tooperator-sdk
commandKUBERNETES_CONTEXT
env varbuildConfigWithContext
toclient.go
With this you can do e.g.:
I've tried to contribute the
buildConfigWithContext
upstream but it was rejected:kubernetes/kubernetes#66329
kubernetes/client-go#192