Change:
* `-f`: Resource file * also used for `--follow` in `logs`, but should be deprecated in favor of `-F` <ins> * `-n`: Namespace scope </ins> * `-l`: Label selector * also used for `--labels` in `expose`, but should be deprecated * `-L`: Label columns

Discussion:
Minor improvement in UX maybe?
We have semi-ambiguous syntax because 'get pod/foo' is also valid. We should have define syntax for this early on. On Apr 8, 2016 7:13 PM, "Prashanth B" wrote:
+1 for the UX improvement.
get pod/foo != get pod ns/foo ?
.... LOL
This would make SO much easier to use :+1:
I dont disagree, but it is somewhat complicated to transition now. Maybe something like 'kind/ns:name' which would be less ambiguous and strictly compatible (ns:name is not a valid name, nor is it confusing wrt kind/name). Need to define precedence of this with --namespace flag and in-file namespace yaml. I also don't see it as a huge win, personally. It would have been nice from day1 but relatively minor now, IMO. But this is a decision for UX team - if someone sent a patch implementing something like it, or at least a proposal that worked through all the details, it would be a better starting place. On Apr 10, 2016 12:33 PM, "Lucas Käldström" wrote:
This is more like P0 to me. Somewhere else I complained about having to type too much and the kind/name syntax. My vote if for kind/ns:name, too.
cc
What is the scenario you're trying to simplify? You often need to use resources from multiple namespaces on the same command line?
cc
ns:name is not a valid name for namespaces and our core resources, but it can be a valid name for extension resources in the Kube ecosystem, like users, roles, authorizations. We'd have to add more slashes
Attaching the namespace to the "name" part won't work well because then you have to chose whether is "list all resources in namespace token" or "get the resource named token in the current namespace". To allow both cases, you must attach the information as a discretely tokenized part or as part of the "resource" part. I think that parses unambiguously since resource can't have dots groups can't have colons and namespaces can't have slashes.
I can assign short names to namespaces and end up with a small kubectl get line, --namespace= just feels unnecessary. I guess it would feel more natural if I could also do .

This isn't a huge deal for me personally because I just bash alias my way out of typing.
In my case, I work with multiple namespaces, not on the same command line (I use --all-namespaces frequently, too). I guess I could create bash aliases, but I also tend to reinstall the machines I run kubectl from on a regular basis.
--all-namespaces is so long anyway that it makes me cringe. , Rudi C wrote:
What api group syntax did we settle on? I don't see it documented anywhere. cc
With Ubernetes, we'll also have multi-cluster scenarios coming.
Syntax is: <resource[[.<version].<group] , Brian Grant wrote:
I think either a short option, like or could be a solution or suffix the namespace using " .
was hoping to save for indicating a for the day when we'd be able to retrieve a historical version of an object via the API. Does not alias to like openshift?
No it does not.
would be an improvement for me: it's noticeably shorter than . Does introduce ambiguities with other flags? or introduce some other issue? or is the hope that there's a nicer unambiguous solution (e.g., something similar to the original proposal)?
I don't know of any conflicts. I'm in favor of the short flag because it gets used all the time.
I am fine with , really appreciate if you could help with this.
We originally had -n in Kube but took it out while we sorted out the other config. We went and it in OpenShift because it was used all the time, but forgot to add it in in kubectl. I think it's time to bring it back to kubectl. Other folks who care about this in kubectl should v oice objections in the next day or so, otherwise I think we have consensus to add as the alias for . Can someone scan over the flags in use today in kubectl and verify that no one has introduced a ? , TonyAdo wrote:
Already did, just client generation. has opened to add this. I've got a minor comments unrelated to the code and tagged to give him a chance to object.
I'm also in favor for adding as a shorthand for