Previously, the `InspectImage` method of the Docker interface expected a
"pullable" image ref (name, tag, or manifest digest).  If you tried to
inspect an image by its ID (config digest), the inspect would fail to
validate the image against the input identifier.  This commit changes
the original method to be named `InspectImageByRef`, and introduces a
new method called `InspectImageByID` which validates that the input
identifier was an image ID.

Automatic merge from submit-queue

Federated deployment controller - part 1

Based on federated replicaset controller (copy + find/replace).

Remaining stuff:
- refacing out common elements to libs
- using owerref in pod analysis
- e2e tests
- renaming concurrency flag for rs and reusing it in deployment
- updating only one cluster at a time if rollingupdate strategy is used.

cc: @quinton-hoole @kubernetes/sig-cluster-federation

**Release note**:

```release-note
Federated deployment controller that supports the same api as the regular kubernetes deployment controller.
```

Automatic merge from submit-queue

kubeadm: turn api into a real apigroup

@kubernetes/sig-cluster-lifecycle

Automatic merge from submit-queue

hack/e2e.go: listen for Interrupt signal and attempt cleanup if run with --down

<!--  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**: adds a listener on ^C, so if `hack/e2e.go` is run with `--down` and the user ^C, then it will attempt to cleanup the resources.

**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`. 
-->
```release-note
NONE
```
Signed-off-by: Jess Frazelle <me@jessfraz.com>

Automatic merge from submit-queue

kubectl: add --revision flag in rollout status

Fixes https://github.com/kubernetes/kubernetes/issues/33185

@kubernetes/kubectl ptal

Automatic merge from submit-queue

refactor controller as posthook when configured and enabled

builds on https://github.com/kubernetes/kubernetes/pull/33785 .

Models the bootstrap controller as a PostHook which is added when its API group is available and its configured.

@liggitt Stefan is out for a while.

Automatic merge from submit-queue

no need to remove file respectively

Automatic merge from submit-queue

Match GroupVersionKind against specific version

Currently when multiple GVK match a specific kind in `KindForGroupVersionKinds` only the first will be matched, which not necessarily will be the correct one. I'm proposing to extend this to pick the best match, instead.

Here's my problematic use-case, of course it involves ScheduledJobs :wink::
I have a `GroupVersions` with `batch/v1` and `batch/v2alpha1` in that order. I'm calling `KindForGroupVersionKinds` with kind `batch/v2alpha1 ScheduledJob` and that currently results this matching first `GroupVersion`, instead of picking more concrete one. There's a [clear description](https://github.com/kubernetes/kubernetes/blob/ee77d4e6ca1e174a189071e50997a377bcb6fc37/pkg/api/unversioned/group_version.go#L183) why it is on single `GroupVersion`, but `GroupVersions` should pick this more carefully.

@deads2k this is your baby, wdyt?

Automatic merge from submit-queue

Small refactoring of scheduler predicates

Ref #34336, #34441

Automatic merge from submit-queue

Rescheduling for critical pods proposal

ref #29023

Automatic merge from submit-queue

[Part 1] Implementation of equivalence pod

Part 1 of #30844

This PR: 

- Refactored `predicate.go`, so that `GetResourceRequest` can be used in other places to `GetEquivalencePod`.
- Implement a `equivalence_cache.go` to deal with all information we need to calculate an equivalent pod.
- Define and register a `RegisterGetEquivalencePodFunction `.

Work in next PR:
- The update of `equivalence_cache.go`
- Unit test
- Integration/e2e test

I think we can begin from the `equivalence_cache.go`? Thanks.  cc @wojtek-t @davidopp 

If I missed any other necessary part, please point it out.

Update equivalent class & remove priority

Use controller ref

Directly clear the cache

Automatic merge from submit-queue

Support upgrade/downgrade in etcd image.

Ref #22448 #20504

Automatic merge from submit-queue

Update documentation for running e2e tests locally

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

The docs for running e2e tests locally needs to be updated.
check_node_count option has been removed and developers usually
need to perform additional steps do get it going.

Automatic merge from submit-queue

fix yaml decode issue

fix #33588

@janetkuo @smarterclayton ptal.

Automatic merge from submit-queue

[Pet Set] petset internal replicas type should be int32

<!--  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**:

Fixes #32993 

Sometimes an int is 4 bytes and sometimes it's 8(depend on CPU architecture), but an int32 is always 32bits. So set petset internal replicas type to int32, avoid type casting in API version converting.

Automatic merge from submit-queue

Fix a formatting string.

Related to #33793

Automatic merge from submit-queue

kubeadm: still run cm if not pod cidr is specified

@kubernetes/sig-cluster-lifecycle

Automatic merge from submit-queue

Generate and store federation OpenAPI spec in source tree

A follow up of #33628 to also add federation spec to source tree.

Automatic merge from submit-queue

Add sandbox gc minage

Fixes https://github.com/kubernetes/kubernetes/issues/34272.
Fixes https://github.com/kubernetes/kubernetes/issues/33984.

This PR:
1) Change the `GetPodStatus` to get statuses of all containers in a pod instead of only containers belonging to existing sandboxes. This is because sandbox may be removed by GC or by users, kubelet should be able to deal with this case.
2) Change the CRI comment to clarify the timestamp unit (nanosecond).
2) Add MinAge for sandbox GC Policy.

@yujuhong @feiskyer @yifan-gu 
/cc @kubernetes/sig-node

Automatic merge from submit-queue

Grab different etcd versions in etcd image.

Ref #20504

@timothysc

Automatic merge from submit-queue

Add support for adding a suffix to the GCS upload dir in jenkins/build

Second step of fixing kubernetes/test-infra#670. Sequences after https://github.com/kubernetes/release/pull/135.

cc @luxas

Automatic merge from submit-queue

Add retry loop around check for /etc/hosts contents to work around issue #34256

See https://github.com/kubernetes/kubernetes/issues/34256

fixes #27023

Automatic merge from submit-queue

kubectl: add two more test of kubectl apply --prune

@pwittrock

Automatic merge from submit-queue

fix replica set hot loop

<!--  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 replicas set hot loop.

Related issue: #30629

Revert "Kubelet: Use RepoDigest for ImageID when available"

Automatic merge from submit-queue

Juju automated charm testing shouldn't bootstrap

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


**Special notes for your reviewer**: This controls the tooling around our test automation. This is a low impact change to the k8s codebase, that will have a big impact on our CI infrastructure.

**Release note**:

```release-note
release-note-none
```

Juju bootstrapping is an act of cost. This should be an explicit action
by the tooling surrounding bundle-tester when testing a charm. Setting
bootstrap:false will allow us to get faster feedback at lower cost when
running the kubernetes charm under ci.

Automatic merge from submit-queue

Check for rsync and give friendlier message

Fixes #34300.

Not sure if #34309 is the same issue.  Hopefully it is the same issue.

Change-Id: I0b8c30083e4a221421de46d9d4dcb21b1f5bb36f

Automatic merge from submit-queue

controller: save older revisions for Deployment's replica sets

@jwforres the only usable way  I could find for multiple old revisions for a single replica set is to stuff them as comma-separated values.

@kubernetes/deployment this retains old revisions served by a replica set inside an annotation.

Fixes https://github.com/kubernetes/kubernetes/issues/33844

Change-Id: I5176eb9350324de8e7b2035686c4e2c2abc5ef3d

Automatic merge from submit-queue

Fix confusing log messages

While debugging https://github.com/kubernetes/kubernetes/issues/33876 , I noticed following confusing message:

``` 
The status of Pod kibana-logging-v1-j99la is Running, waiting for it to be either Running or Failed
```