Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Modify e2e tests to use priorityClass beta client version & switch priorityClass to beta
**What this PR does / why we need it**:
/cc @bsalamat @aveshagarwal @liggitt
**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
Part of #57471
**Special notes for your reviewer**:
Once #57963 merges, this could go in.
**Release note**:
```release-note
Modify e2e tests to use priorityClass beta version & switch priorityClass feature to beta
```
Automatic merge from submit-queue (batch tested with PRs 63871, 63927, 63966, 63957, 63844). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
start splitting polymorphic functions out of the factory
the polymorphic behavior in `kubectl` has been gathered in the factory, but with the new kubeconfigflags and interfaces, it can actually be re-written as a set of helper calls.
These functions are special. They are indications of areas of flexibility that we eventually need to build generically. In addition, unit tests make heavy use of injection. For these reasons we aren't inlining them. Instead we'll extra to a polymorphic package and have them as assignable functions for mocking.
Individual commands should support injection for cleaner mocking and we'll be able to use the package to hunt internal dependencies.
@kubernetes/sig-cli-maintainers
@soltysh @juanvallejo
```release-note
NONE
```
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Allow for listing & watching individual secrets from nodes
This PR:
- propagates value of `metadata.name` field from fieldSelector to `name` field in RequestInfo (for list and watch requests)
- authorizes list/watch for requests for single secrets/configmaps coming from nodes
As an example:
```
/api/v1/secrets/namespaces/ns?fieldSelector=metadata.name=foo =>
requestInfo.Name = "foo",
requestInfo.Verb = "list"
/api/v1/secrets/namespaces/ns?fieldSelector=metadata.name=foo&watch=true =>
requestInfo.Name = "foo",
requestInfo.Verb = "list"
```
```release-note
list/watch API requests with a fieldSelector that specifies `metadata.name` can now be authorized as requests for an individual named resource
```
Automatic merge from submit-queue (batch tested with PRs 63624, 59847). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
explicit kubelet config key in Node.Spec.ConfigSource.ConfigMap
This makes the Kubelet config key in the ConfigMap an explicit part of
the API, so we can stop using magic key names.
As part of this change, we are retiring ConfigMapRef for ConfigMap.
```release-note
You must now specify Node.Spec.ConfigSource.ConfigMap.KubeletConfigKey when using dynamic Kubelet config to tell the Kubelet which key of the ConfigMap identifies its config file.
```
This makes the Kubelet config key in the ConfigMap an explicit part of
the API, so we can stop using magic key names.
As part of this change, we are retiring ConfigMapRef for ConfigMap.
Automatic merge from submit-queue (batch tested with PRs 62937, 63105, 63031, 63174). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
rest mappings cannot logically be object converters
A `RESTMapping` in the general sense cannot be a `ObjectConverter` since the conversions are compiled, but the RESTMappings are discovered. This starts isolating the bad assumptions into `kubectl` where they are used and removes the other bad `RESTMapping` use I found in the REST API installer that uses a mapping to determine scopes instead of using the metadata provided during API registration.
intersection of @kubernetes/sig-api-machinery-bugs and @kubernetes/sig-cli-maintainers
@sttts @pwittrock @soltysh
```release-note
NONE
```
builds on #62868
1. When the incoming patch specified a resourceVersion that failed as a precondition,
the patch handler would retry uselessly 5 times. This PR collapses onto GuaranteedUpdate,
which immediately stops retrying in that case.
2. When the incoming patch did not specify a resourceVersion, and persisting to etcd
contended with other etcd updates, the retry would try to detect patch conflicts with
deltas from the first 'current object' retrieved from etcd and fail with a conflict error
in that case. Given that the user did not provide any information about the starting version
they expected their patch to apply to, this does not make sense, and results in arbitrary
conflict errors, depending on when the patch was submitted relative to other changes made
to the resource. This PR changes the patch application to be performed on the object retrieved
from etcd identically on every attempt.
fixes#58017
SMP is no longer computed for CRD objects
fixes#42644
No special state is retained on the first attempt, so the patch handler correctly handles
the cached storage optimistically trying with a cached object first
Antoine Pelisse