Automatic merge from submit-queue

Node E2E: Fix remote node e2e focus.

Before, we use `'focus'` and `'skip'` in `hack/make-rules/test-e2e-node.sh`.

When we run `make test-e2e-node REMOTE=true FOCUS="Some Thing"`, it will eventually be translated to `-focus='Some Thing'` [here](https://github.com/kubernetes/kubernetes/blob/master/test/e2e_node/remote/remote.go#L284-L285).

However, golang `exec.Command` wraps each argument with single quote, the argument will become `'xx -focus='Some Thing' xx'`, and cause error because of the 2 layer single quote.

Automatic merge from submit-queue

Fix salt master check using hard coded string

<!--  Thanks for sending a pull request!  Here are some tips for you:
1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md
2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md
3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes
-->

**What this PR does / why we need it**:
**Which issue this PR fixes** 
This is for vsphere only.

If var $INSTANCE_PREFIX is changed in cluster/vsphere/config-default.sh, then salt master check will fail due to the hard coded string "kubernetes-master".  The fix uses $MASTER_NAME instead.

**Special notes for your reviewer**:

**Release note**:
<!--  Steps to write your release note:
1. Use the release-note-* labels to set the release note state (if you have access) 
2. Enter your extended release note in the below block; leaving it blank means using the PR title as the release note. If no release note is required, just write `NONE`. 
-->
```release-note
```

Automatic merge from submit-queue

 replace if with else-if

<!--  Thanks for sending a pull request!  Here are some tips for you:
1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md
2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md
3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes
-->

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

I replace if with else-if

Thanks!

**Special notes for your reviewer**:

**Release note**:
<!--  Steps to write your release note:
1. Use the release-note-* labels to set the release note state (if you have access) 
2. Enter your extended release note in the below block; leaving it blank means using the PR title as the release note. If no release note is required, just write `NONE`. 
-->
```release-note
```

Automatic merge from submit-queue

Improved validation error message when env.valueFrom contains no (or …

<!--  Thanks for sending a pull request!  Here are some tips for you:
1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md
2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md
3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes
-->

**What this PR does / why we need it**:
A misleading error message is shown if the user mistypes (or forgets to specify) a field under env.valueFrom. This is the error message: "may not have more than one field specified at a time". But there is only one (misspelled) field specified.


**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #

**Special notes for your reviewer**:

**Release note**:
<!--  Steps to write your release note:
1. Use the release-note-* labels to set the release note state (if you have access) 
2. Enter your extended release note in the below block; leaving it blank means using the PR title as the release note. If no release note is required, just write `NONE`. 
-->
```
Improved error message for missing/misspelled field under env.valueFrom
```

Automatic merge from submit-queue

Mention overflows when mistakenly call function FromInt

**What this PR does / why we need it**:
When mistakenly call this method with a value that overflows int32 will causes strange behavior in some environment (maybe in amd64 system, i'm not sure but my test shows that).
For example, call FromInt(93333333333) would result in -1155947179 and not mention overflows.

Automatic merge from submit-queue

skip test docker if we do not use docker as container runtime.

skip test docker if we do not use docker as container runtime.
Signed-off-by: Xianglin Gao <xlgao@zju.edu.cn>

Automatic merge from submit-queue

federation service e2e: Creating configmap for kube-dns

Ref #37105 and #37143.

Creating kube-dns config map to pass federations flag to kube-dns.
This is required since we moved to the new add on manager. With the old add on manager, we were using kube-dns rc that included the federations flag.

cc @kubernetes/sig-cluster-federation @madhusudancs @bowei @MrHohn 

Verified that the tests pass with this change.

Automatic merge from submit-queue

Update doc for kubectl apply

Update doc for `kubectl apply`.

@MrHohn @mikedanese Please review the changes related to `--prune`.

We will need to update the doc when flags `--dry-run` and `-o` have been fixed. Ref: https://github.com/kubernetes/kubernetes/pull/34028#issuecomment-262392748

Partially addresses: kubernetes/kubernetes.github.io#1513

cc: @pwittrock @foxish

Automatic merge from submit-queue

Removes shorthand flag -w from kubectl apply

Fixes #37342.

A shorthand flag `-w` was introduced as flag `--prune-whitelist` for kubectl apply two weeks ago. Turned out it is not what we should do. Removing this shorthand flag before 1.5 release to prevent further issues.

@ymqytw @pwittrock

Automatic merge from submit-queue

Log when pod expires in scheduler

Ref #37232

Automatic merge from submit-queue

Fix typo in e2e tests doc

Automatic merge from submit-queue

Update kubeadm etcd to 3.0.13 in order to switch to the etcd3 storage format

ref: https://github.com/kubernetes/kubernetes/issues/35723

I think we should switch as soon as possible, but run it in etcd2 mode until the full etcd3 mode is stable

@kubernetes/sig-cluster-lifecycle @wojtek-t @xiang90 @lavalamp

Automatic merge from submit-queue

Update kubectl drain help message

Update `kubectl drain` help messages according to kubernetes/kubernetes.github.io#1768

cc: @erictune @pwittrock

Automatic merge from submit-queue

Fixing a typo in deployment e2e

Ref https://github.com/kubernetes/kubernetes/issues/37105 and https://github.com/kubernetes/kubernetes/issues/37143.

Fixing the failing deployment e2e.
There are 3 deployment cases failing right now. https://github.com/kubernetes/kubernetes/pull/37290 fixes the first and this PR fixes the other 2.

cc @kubernetes/sig-cluster-federation @madhusudancs @mwielgus

Automatic merge from submit-queue

Enable PDB e2e tests on GKE

cc: @davidopp

Automatic merge from submit-queue

Add missing variable to openstack provider

`FIXED_NETWORK_CIDR` environment variable is mandatory by
openstack-heat kubernetes provider, but it's missing as
default value. Adding this environment variable is helpful
to build kubernetes cluster using openstack-heat provider.
So this patch adds it.

Automatic merge from submit-queue

Improve error logging in glusterfs provisioner

- log `err` if it is known
- unify log message style

Automatic merge from submit-queue

Add more debug information around strange failure in e2e tests

To better understand problems in https://github.com/kubernetes/kubernetes/issues/33754. 

cc: @fgrzadkowski @piosz

Automatic merge from submit-queue

fix the mistake type

<!--  Thanks for sending a pull request!  Here are some tips for you:
1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md
2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md
3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes
-->

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

**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #

**Special notes for your reviewer**:

**Release note**:
<!--  Steps to write your release note:
1. Use the release-note-* labels to set the release note state (if you have access) 
2. Enter your extended release note in the below block; leaving it blank means using the PR title as the release note. If no release note is required, just write `NONE`. 
-->
```release-note
```
Signed-off-by: yupeng <yu.peng36@zte.com.cn>

Automatic merge from submit-queue

Fix notice in redis-slave example

Automatic merge from submit-queue

eliminate kuberentes

Luckily only caught one from echo!

@kubernetes/test-infra-maintainers 

<!--  Thanks for sending a pull request!  Here are some tips for you:
1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md
2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md
3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes
-->

**What this PR does / why we need it**:
It's important, and really hard, to identify kuberentes from kubernetes. As a human being, one's brain tends to auto fix the spelling for you thus when a dev was staring at the log for a good 30-min or so he will start question about his life and belief.

Luckily this is the only place in k/k, it's super important to fix it to avoid future pain.

**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #

**Special notes for your reviewer**:

**Release note**:
<!--  Steps to write your release note:
1. Use the release-note-* labels to set the release note state (if you have access) 
2. Enter your extended release note in the below block; leaving it blank means using the PR title as the release note. If no release note is required, just write `NONE`. 
-->
```release-note
```

Automatic merge from submit-queue

Clean up some wording

The wording felt a little clunky so I tried to smooth it out a little. Hopefully I maintained the author's intent.

Automatic merge from submit-queue

fix a typo I noticed while reading some code.

Automatic merge from submit-queue

fix typo in podaffinity.md

Automatic merge from submit-queue

Curating Owners: pkg/apis

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

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

Remove a few versioned-warnings that snuck in, again

Automatic merge from submit-queue

Added comments on running update-bazel.sh in "$GOPATH/src/k8s.io/kubernetes"

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

This path made `hack/update-bazel.sh` to accept `$GOPATH` with multiple path.

Automatic merge from submit-queue

fix error description

<!--  Thanks for sending a pull request!  Here are some tips for you:
1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md
2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md
3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes
-->

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

Fix error description.

Thanks

**Special notes for your reviewer**:

**Release note**:
<!--  Steps to write your release note:
1. Use the release-note-* labels to set the release note state (if you have access) 
2. Enter your extended release note in the below block; leaving it blank means using the PR title as the release note. If no release note is required, just write `NONE`. 
-->
```release-note
```

Automatic merge from submit-queue

Fix container to pod in resource-qos.md

`...then the container is classified as Guaranteed.`
Here `container` should be `pod`.

Automatic merge from submit-queue

Add reviewable notes to CONTRIBUTING

@kubernetes/contributor-experience

Automatic merge from submit-queue

Update gluster setup readme.

Referring gluster setup guide to official glusterfs documentation. 
Signed-off-by: Humble Chirammal <hchiramm@redhat.com>

Automatic merge from submit-queue

Curating Owners: build-tools/kube-dns

cc @thockin @artfulcoder

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/proxy

cc @thockin

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

Add CONTRIBUTING section on build

@kubernetes/contributor-experience

Automatic merge from submit-queue

update gazel usage in bazel.md

**What this PR does / why we need it**:
Now run the newest gazel have to specify the '-root' argument to update a single BUILD file.
So updated the gazel usage.

Automatic merge from submit-queue

Fix doc links in Federation readme

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

The user guide and admin guide links were swapped round

**Release note**: NONE

Automatic merge from submit-queue

Reduce verbosity of volume reconciler

**What this PR does / why we need it**:
It reduces the log verbosity for attaching of volumes

**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #

**Special notes for your reviewer**:

**Release note**:
```release-note
Reduce verbosity of volume reconciler when attaching volumes
```

Set logging level for information about attaching of volumes to from 1 to 4
Otherwise the log is spammed with one line per 100ms while attaching is
in progress and afterwards as long as the volume is attached.