Automatic merge from submit-queue

Don't blame DNS spec on Kubernetes requirement for lower-case DNS labels.

**What this PR does / why we need it**: #39635 was rejected because it wasn't clear to the author (me) that lower-case DNS labels are in fact a [Kubernetes requirement](https://github.com/kubernetes/kubernetes/pull/39635#issuecomment-271404975) rather than from the [DNS RFC 1035](https://www.ietf.org/rfc/rfc1035.txt) or/and [DNS RFC 1123](https://www.ietf.org/rfc/rfc1123.txt).

**Special notes for your reviewer**: @thockin this is a first pass to make the error messages clearer about the fact that DNS specs are not to _blame_.

Automatic merge from submit-queue (batch tested with PRs 39609, 39105)

Stop running most unit tests outside of bazel.

Lets not duplicate our efforts. The two I still run here are the two we currently skip in bazel. We should fix those.

Automatic merge from submit-queue

Remove sleep from DynamicProvisioner test.

The comment says that the sleep is there because of 10 minute PV controller
sync. The controller sync is now 15 seconds and it should be quick enough
to hide this in subsequent `WaitForPersistentVolumeDeleted(.. , 20*time.Minute)`

Automatic merge from submit-queue (batch tested with PRs 38427, 39896, 39889, 39871, 39895)

Fix expected error text

I had initially coded the expected text to match what was coming out of stderr, which was wrong. This makes it match against what comes from stdout.

Automatic merge from submit-queue (batch tested with PRs 38427, 39896, 39889, 39871, 39895)

Conditionally write token file entries

Fixes #39863

We have a bigger problem with not knowing what is calling these functions, but this will at least tolerate callers that are not setting the envvars we expect

Automatic merge from submit-queue (batch tested with PRs 38427, 39896, 39889, 39871, 39895)

Add docker 1.12 in node e2e.

Add docker 1.12 image in node e2e (including regular node e2e and cri node e2e).

@dchen1107 @yujuhong 
/cc @kubernetes/sig-node-misc

Automatic merge from submit-queue (batch tested with PRs 38427, 39896, 39889, 39871, 39895)

Grant permissions to e2e examples test service account

ref #39382

Automatic merge from submit-queue (batch tested with PRs 38427, 39896, 39889, 39871, 39895)

gitattributes for better reviews

Reviewable will ignore files marked as -diff.

Automatic merge from submit-queue

Generate protobuf into vendor for pseudo vendored models

Fixes #39764

@ncdc

Automatic merge from submit-queue

Updated unit tests

@janetkuo updated the flaky unit test to have the same structure with regard to uncasting as the rest of the tests. ptal

Automatic merge from submit-queue

Curating Owners: pkg/conversion

cc @lavalamp @smarterclayton @wojtek-t @derekwaynecarr

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

Only set empty list for list types

If List() impls return non-list objects (like Status objects), we shouldn't try to set them to an empty list

follow up to #39834

Automatic merge from submit-queue

Curating Owners: pkg/master

cc @lavalamp @nikhiljindal @mikedanese @derekwaynecarr

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

Curating Owners: pkg/storage

cc @lavalamp @timothysc @liggitt @xiang90 @wojtek-t

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

Curating Owners: pkg/auth/

cc @liggitt @erictune

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.

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 are 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)

Merge pull request #37667 from bruceauyeung/k8s-branch-eliminate-duplicated-codes-in-estimateContainer-method

Automatic merge from submit-queue

eliminate duplicated codes in estimateContainer method

**What this PR does / why we need it**:
there are two code snippets about when to estimate resource for cpu and mem are duplicated, i extracted them into method `getEstimationIfNeeded` method
Signed-off-by: bruceauyeung <ouyang.qinhua@zte.com.cn>

replace contents of docs/design with stubs

Automatic merge from submit-queue

Curating Owners: cmd/kube-controller-manager

cc @lavalamp @mikedanese

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

Curating Owners: pkg/credentialprovider

cc @liggitt @erictune

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 (batch tested with PRs 37505, 39844, 39525, 39109, 39303)

remove NewManager() return err

Automatic merge from submit-queue (batch tested with PRs 39807, 37505, 39844, 39525, 39109)

Admission control support for versioned configuration files

**What this PR does / why we need it**:
Today, the `--admission-control-config-file=` argument takes an opaque file that is shared across all admission controllers to provide configuration.  This file is not well-versioned and it's shared across multiple plug-ins.  Some plugins take file based configuration (`ImagePolicyWebhook`) and others abuse flags to provide configuration because we lacked a good example (`InitialResources`).  This PR defines a versioned configuration format that we can use moving forward to provide configuration input to admission controllers that is well-versioned, and does not require the addition of new flags.

The sample configuration file would look as follows:

```
apiVersion: componentconfig/v1alpha1
kind: AdmissionConfiguration
plugins:
- name: "ImagePolicyWebhook"
  path: "image-policy-webhook.json"
```

The general behavior is each plugin that requires additional configuration is enumerated by name.  An alternate file location is provided for its specific configuration, or the configuration can be embedded as a raw extension via the configuration section.

**Special notes for your reviewer**:
A follow-on PR will be needed to make `ImagePolicyWebhook` to use versioned configuration.  This PR maintains backwards compatibility by ignoring configuration it cannot understand and therefore treating the file as opaque.  I plan to make use of this PR to complete https://github.com/kubernetes/kubernetes/pull/36765 which attempts to allow more configuration parameters to the `ResourceQuota` admission plugin.

Automatic merge from submit-queue (batch tested with PRs 39807, 37505, 39844, 39525, 39109)

Update deployment equality helper

@mfojtik @janetkuo this is split out of https://github.com/kubernetes/kubernetes/pull/38714 to reduce the size of that PR, ptal

Automatic merge from submit-queue (batch tested with PRs 39807, 37505, 39844, 39525, 39109)

fix bug not using volumetype config in create volume

fixes #39843 

@humblec 

we are building the volumetype config but I don't see where we are using it in the CreateVolume for dyn provisioning, this is why volumetype parameter from the Storage Class was being overlooked because we are hard coding constants like replicaCount which is always 3.

unless I'm missing something?

Automatic merge from submit-queue (batch tested with PRs 39807, 37505, 39844, 39525, 39109)

Made cache.Controller to be interface.

**What this PR does / why we need it**:

#37504

Automatic merge from submit-queue

run staging client-go update

Chasing to see what real problems we have in staging-client-go.

@sttts you get similar results?

Automatic merge from submit-queue

Curating Owners: pkg/quota

cc @vishh @derekwaynecarr

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

replace global registry in apimachinery with global registry in k8s.io/kubernetes

We'd like to remove all globals, but our immediate problem is that a shared registry between k8s.io/kubernetes and k8s.io/client-go doesn't work.  Since client-go makes a copy, we can actually keep a global registry with other globals in pkg/api for now.

@kubernetes/sig-api-machinery-misc @lavalamp @smarterclayton @sttts

Automatic merge from submit-queue

break from the for loop

**What this PR does / why we need it**:

exit loop, because the following actions will not affect the result

**Special notes for your reviewer**:

**Release note**:

```release-note
```

Automatic merge from submit-queue

Curating Owners: cmd/kube-apiserver

cc @lavalamp @smarterclayton @krousey @nikhiljindal

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)