Automatic merge from submit-queue (batch tested with PRs 38720, 38533)
Priority REST Mapper: Actually honor user choice
```release-note
Fixes bug in resolving client-requested API versions
```
RESTMapping takes a desired GroupKind, and a set of versions, and
returns a rest mapper for the first matching version. It also has a
list of built-in discovered prioritized versions, to which it appends
the user versions.
However, when it goes to parse the versions, it parses them as
GroupVersions. Since only a version was passed, the group will be the
empty group (""), which will only match rest mappings for the empty
group, ergo, none of the user's versions will match if they are
attempting a match for a non-emtpy-group GroupKind.
This fixes that by taking the parsed GroupVersion, and overriding the
Group with the Group from the passed-in GroupKind.
RESTMapping takes a desired GroupKind, and a set of versions, and
returns a rest mapper for the first matching version. It also has a
list of built-in discovered prioritized versions, to which it appends
the user versions.
However, when it goes to parse the versions, it parses them as
GroupVersions. Since only a version was passed, the group will be the
empty group (""), which will only match rest mappings for the empty
group, ergo, none of the user's versions will match if they are
attempting a match for a non-emtpy-group GroupKind.
This fixes that by taking the parsed GroupVersion, and overriding the
Group with the Group from the passed-in GroupKind.
RESTMapping method can now rely on RESTMappings by passing versions parameter and taking the first match found by RESTMappings method. In addition
a UT that test the new method has been added.
The only change in logic to what was before is when calling RESTMapping
we search all defaultGroupVersion as opposed to just one when no mapping was found for provided versions.
Automatic merge from submit-queue
Curating Owners: pkg/api
cc @lavalamp @smarterclayton @erictune @thockin @bgrant0607
In an effort to expand the existing pool of reviewers and establish a
two-tiered review process (first someone lgtms and then someone
experienced in the project approves), we are adding new reviewers to
existing owners files.
If You Care About the Process:
------------------------------
We did this by algorithmically figuring out who’s contributed code to
the project and in what directories. Unfortunately, that doesn’t work
well: people that have made mechanical code changes (e.g change the
copyright header across all directories) end up as reviewers in lots of
places.
Instead of using pure commit data, we generated an excessively large
list of reviewers and pruned based on all time commit data, recent
commit data and review data (number of PRs commented on).
At this point we have a decent list of reviewers, but it needs one last
pass for fine tuning.
Also, see https://github.com/kubernetes/contrib/issues/1389.
TLDR:
-----
As an owner of a sig/directory and a leader of the project, here’s what
we need from you:
1. Use PR https://github.com/kubernetes/kubernetes/pull/35715 as an example.
2. The pull-request is made editable, please edit the `OWNERS` file to
remove the names of people that shouldn't be reviewing code in the
future in the **reviewers** section. You probably do NOT need to modify
the **approvers** section. Names asre sorted by relevance, using some
secret statistics.
3. Notify me if you want some OWNERS file to be removed. Being an
approver or reviewer of a parent directory makes you a reviewer/approver
of the subdirectories too, so not all OWNERS files may be necessary.
4. Please use ALIAS if you want to use the same list of people over and
over again (don't hesitate to ask me for help, or use the pull-request
above as an example)
Automatic merge from submit-queue
SetSelfLink is inefficient
Generating self links, especially for lists, is inefficient. Replace
use of net.URL.String() call with direct encoding that reduces number of
allocations. Switch from calling meta.ExtractList|SetList to a function
that iterates over each object in the list.
In steady state for nodes performing frequently small get/list
operations, and for larger LISTs significantly reduces CPU and
allocations.
@wojtek-t this is the next big chunk of CPU use during the large N nodes simulation test (11% of master CPU). Takes a few allocations out of the critical path
Generating self links, especially for lists, is inefficient. Replace
use of net.URL.String() with direct encoding that reduces number of
allocations. Switch from calling meta.ExtractList|SetList to a function
that iterates over each object in the list.
In steady state for nodes performing frequently small get/list
operations, and for larger LISTs significantly reduces CPU and
allocations.
The GC needs to build clients based only on Resource or Kind. Hoist the
restmapper out of the controller and the clientpool, support a new
ClientForGroupVersionKind and ClientForGroupVersionResource, and use the
appropriate one in both places.
Convert single GV and lists of GVs into an interface that can handle
more complex scenarios (everything internal, nothing supported). Pass
the interface down into conversion.
With the introduction of batch/v1 and batch/v2alpha1, any
MultiRESTMapper that has per groupversion mappers (as a naive discovery
client would create) would end up being unable to call RESTMapping() on
batch.Jobs. As we finish up discovery we will need to be able to choose
prioritized RESTMappings based on the service discovery doc.
This change implements RESTMappings(groupversion) which returns all
possible RESTMappings for that kind. That allows a higher level call to
prioritize the returned mappings by server or client preferred version.
Callers are required to implement their interfaces, removes the
potential for mistakes. We have a reflective test
pkg/api/meta_test.go#TestAccessorImplementations that verifies that all
objects registered to the scheme properly implement their interfaces.
Make unversioned.ListMeta implement List. Update all the *List types so they implement GetListMeta.
This helps avoid using reflection to get list information.
Remove all unnecessary boilerplate, move the interfaces to the right
places, and add a test that verifies that objects implement one, the
other, but never both.
Add accessor methods that implement pkg/api/unversioned.ObjectKind,
pkg/api/meta.Object, pkg/api/meta.Type and pkg/api/meta.List.
Removed the convenience fields since writing to them was not reflected
in serialized JSON.
Automatic merge from submit-queue
relax restmapper resource matching
We were matching case insensitive on Kinds, not Resources, thus driving me insane.
@liggitt @caesarxuchao
deads2k