@caesarxuchao @janetkuo

/cc @kubernetes/rh-cluster-infra

Do we support these?

• kubectl operation group/resource
• kubectl operation group/resource/name
• kubectl operation group resource
• kubectl operation group resource name

When the group isn't provided, we assume it's empty or find the first match?

I think if group is not provided, then we should see what groups the resource could possibly be inside; if there's only 1, great. If there's more than one, we should error out.

Likewise it shouldn't be ambiguous whether kubectl get a b is group/resource or resource/name, because presumably we won't have groups named e.g. "pods" or resources named e.g. "experimental"; but if we do have those cases, we should force the user to be explicit rather than do something surprising.

I don't have opinions on whether '/', ' ', or both should be allowed as separators.

So to do that, kubectl would need to get (or maintain) a map of resource -> (group, resource). We should get that from apiserver, not by looking at the resources compiled into kubelet.

TODOs:

• make kubectl <operation> group/resource name and kubectl <operation> group/resource work (Support kubectl group/resource name #14461)
• update kubectl help text for api group
• kubectl --api-version and --output-version flag should accept values in the form of group/version, and should work as they do today. For multi-resource operations we'll disable these 2 flags.
  • replace --api-version with --preferred-versions (Deprecate api-version field in kubeconfig file #14383)
• pkg/client: api version to be set at high level, not low level. (pkg/client: api version to be set at high level, not low level. #14133)
  • remove references to "version" from the RESTClient (pkg/client/unversioned#RESTClient)
  • put them in the high level client, adding Group(), Version(), and GroupVersion() calls to the client.Request (pkg/client/unversioned#Request) object
  • store group/version information in resource.Helper (pkg/kubectl/resource#Helper)

@janetkuo, just in case you don't know this already, as stated in the proposal:
"When kubectl is used with a single resource type, the --api-version and --output-version flag of kubectl should accept values in the form of group/version, and they should work as they do today. For multi-resource operations, we will disable these two flags initially."

as we think about this, we should also consider whether subresources (which kubectl doesn't support today) should be addressable, and how

@kubernetes/kubectl

It seems some TODOs still not finished, will pick one.

We now support resource.version.group for kubectl commands: #22853

#22454 tracks what we should do about --api-version and --output-version.

I guess we can close this issue?

I guess we can close this issue?

I think we'll still have problems specifying api-versions for names retrieved from files and for commands that don't take resource strings like cordon as a for instance. We don't use those often downstream, have you guys already figured out what to do about those?

I think cordon can handle resource strings.

Is this still an issue?

Please file more specific issues for any remaining problems.