-
Notifications
You must be signed in to change notification settings - Fork 101
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
genericclioptions: Inferring namespace from config flag or kubeconfig #9
Comments
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/lifecycle frozen |
Ah, this is likely happening because the methods like IMO, shouldn't |
I'm trying to implement a very simple "kubectl get" using pkg/genericclioptions.
In my command, I see
--namespace
option registered.When I invoke my command, I don't specify any value for
--namespace
, because I expect that it will read the kubeconfig (using default loading rules) and find the current namespace name (if set), otherwise will assume "default".However, when I create a client and query, I get no namespace segment in URLs, so my Get() requests are failing with 404.
How is someone supposed to automatically have namespace field populated while using genericclioptions?
Here's what I'm doing:
I have tried doing
dyn.Resource(apiRes).Namespace(*cf.Namespace).Get(...)
but since--namespace
is not specified it won't do anything.Since I use ToRESTConfig() method, I expect this package to automatically find my namespace (from kubeconfig) or assume "default" and inject that to the URL.
Why is this not happening?
The text was updated successfully, but these errors were encountered: