fix: prefer core resources when enabling a type

[makkes]

What this PR does / why we need it:
When a resource type such as pods is services is passed to
kubefedctl enable and there's a match for this name in the core
group as well as another group, there was no way to tell kubefedctl
that the core resource should be enabled.

Now, whenever an API resource from the core group matches the
desired type to be enabled, this resource type is preferred.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #1078

Special notes for your reviewer:
Here's the steps to test this:

• kind create cluster
• kubectl apply --filename https://github.com/knative/serving/releases/download/v0.18.0/serving-crds.yaml
• make kubefedctl
• ./bin/kubefedctl enable services --kubefed-namespace="default" -o yaml

Before this change:

$ ./bin/kubefedctl enable services --kubefed-namespace="default" -o yaml
F1012 22:22:47.217201   66506 enable.go:111] Error: Multiple resources are matched by "services": services, services.serving.knative.dev. A group-qualified plural name must be provided.

With this change:

$ ./bin/kubefedctl enable services --kubefed-namespace="default" -o yaml
---
apiVersion: core.kubefed.io/v1beta1
kind: FederatedTypeConfig
[...]

[makkes]

/assign @jimmidyson

[irfanurrehman]

@makkes thanks for doing this.
The implicitly selection of core when no group is specified and the core group is in the matches, seems fine to me.
However, it should be documented simply because its implicit. I think a good place to put it would be here in someway referring to details mentioned here.
Can you please do that.

[jimmidyson]

I wonder if we should do the same as kubectl does and follow API group/version priority when short names (or unqualified as in this case) are used?

[makkes]

@jimmidyson do you have a hint where I would find out how kubectl does it?

[jimmidyson]

@makkes Check out k8s.io/client-go/discovery package, which allows you to list server resources.

[makkes]

I wonder if we should do the same as kubectl does and follow API group/version priority when short names (or unqualified as in this case) are used?

We're already using ServerPreferredResources() to fetch resources to consider so already following kubectl's approach with regards to order. The only difference being that we error out when multiple resources match. In the service of keeping backwards-incompatible changes to a minimum, I would prefer to leave this PR as it is and follow-up with a PR that changes semantics to align with kubectl's approach more.

@jimmidyson wdyt?

[jimmidyson]

This PR effectively puts core v1 API as higher priority than anything else, which is reasonable and fixes the reported bug, so I'm happy to approve this PR as-is and follow up with a PR that aligns with kubectl semantics. I agree with @irfanurrehman that this should be documented and then we can get this merged.

I think we can clean up the code quite a bit by using discovery client smarter, something like:

restMapper := restmapper.NewDeferredDiscoveryRESTMapper(discoveryClient)
shortcutRestMapper := restmapper.NewShortcutExpander(restMapper, discoveryClient)

gvks, err := shortcutRestMapper.KindsFor(schema.GroupVersionResource{Group: optionalGroup, Version: optionalVersion, Resource: resource})

[makkes]

I agree and will add documentation soon!

[makkes]

@irfanurrehman @jimmidyson I added a section to the user guide.

[jimmidyson]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jimmidyson, makkes

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [jimmidyson]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[irfanurrehman]

/lgtm