…jq 'select(.Version!="v0.0.0")') > Godeps/Godeps.json

The tests need to be rewritten to be safe for concurrent use and for
work in contended environments. Disabling the worst offenders and fixing
reuse issues around the tests here.

Origin-commit: b6281a54c84f20c2f0d35d6a44881e83b2e75227

Origin-commit: 2967069b36915643acca58da463753ba5b115759

…oud: make sure that the secondary zone is also part of managedZones

The DefaultTestClusterValues has two zones `ZoneName, ScondaryZoneName` set [1], but the FakeGCECloud would only use ZoneName as managedZone.

So `TestUpdateInternalLoadBalancerNodes` that adds nodes and instancegroups in both zones fails with NotFound errors

[1]: https://github.com/kubernetes/kubernetes/blob/bb052ceacb86d0603a5c2053a8c2c0c96abf83c5/staging/src/k8s.io/legacy-cloud-providers/gce/gce_fake.go#L45-L47

Origin-commit: 79d66e294a3906efd0351f125cefb4b9cc1c9ab4

…oups for internal load balancers

Based on docs for internal loadbalancer here [1], backend services [2] and instances in instance-groups [3], following restrictions apply,

- Internal LB can load balance to VMs in same region, but different subnets
- Instance groups for the backend service must contain instance of the same subnet
- An instance can only belong to one load balanced instance group

It is probably useful use-case to have nodes for the cluster belong to more than one subnet. And the current setup fails to create an internal load balancer with nodes in multiple subnets.

```
I1023 22:05:24.070949       1 gce_loadbalancer_internal.go:478] ensureInternalInstanceGroup(k8s-ig--27083f8254ed83c2, us-west1-b): adding nodes: [jstuev-5hzjp-m-1.c.openshift-dev-installer.internal jstuev-5hzjp-w-b-54qkc.c.openshift-dev-installer.internal]
E1023 22:05:25.385077       1 gce_loadbalancer.go:156] Failed to EnsureLoadBalancer(jstuev-5hzjp, openshift-ingress, router-default, a79c0f796db9e4157af2e2658433b3f6, us-west1), err: googleapi: Error 400: Resource 'projects/openshift-dev-installer/zones/us-west1-b/instances/jstuev-5hzjp-w-b-54qkc' is expected to be in the subnetwork 'projects/openshift-dev-installer/regions/us-west1/subnetworks/jstubyo-master-subnet' but is in the subnetwork 'projects/openshift-dev-installer/regions/us-west1/subnetworks/jstubyo-worker-subnet'., wrongSubnetwork
```

Also the use-case that some of these nodes (machines) might be part of some internal load balancer that is not managed by k8s is also pretty valid.
for example, you might have the machines hosting the control-plane (kube-apiserver) want to be part of a separate ILB that provides access to the apiserver through LB not managed by the k8s Service type Load Balancer.
But the current setup fails to create an interal load balancer like

```
r: failed to ensure load balancer: googleapi: Error 400: INSTANCE_IN_MULTIPLE_LOAD_BALANCED_IGS - Validation failed for instance 'projects/openshift-dev-installer/zones/us-west1-a/instances/jstuev-t285j-m-0': instance may belong to at most one load-balanced instance group.
```

So the subnet limitation should be automatically handled by the k8s cloud provider, but for now allowing users to create the IGs for instances that require this special setup should definietly help, and k8s cloud provider can just use those as-is, while maintaining the membership and lifecycle for ones created by it.

This change finds pre-existing instance-groups that ONLY contain instances that belong to the cluster, uses them for the backend service. And only ensures instance-groups for remaining ones.

[1]: https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-unmanaged-instances#addinstances
[2]: https://cloud.google.com/load-balancing/docs/backend-service#restrictions_and_guidance
[3]: https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-unmanaged-instances#addinstances

Origin-commit: cfb25370a7c8f9bed9688cb334b4bc1c3342da0d

Skip the "Deployment should not disrupt a cloud load-balancer's
connectivity during rollout" test if the number of nodes is less than 2;
otherwise, set the deployment's replicas equal to the lesser of 5 and the
number of nodes.

The test would fail if there were fewer nodes than replicas, but the test
needs at least 2 nodes, and the likelihood of failure absent the feature
under test increases with the number of replicas, so it is desirable to set
replicas to a higher value, within reason.

Follow-up to commit 980b640.

* vendor/k8s.io/kubernetes/test/e2e/apps/deployment.go: Skip the
load-balancer connectivity test unless there are at least 2 nodes.
(testRollingUpdateDeploymentWithLocalTrafficLoadBalancer): Set replicas to
the min of 5 and the number of nodes.

Origin-commit: 3f09c3e5cd2f0a52e7549b376aefbb62b308dc7b

…ance groups that will be re-used for ILB backend

Setting the prefix would allow cluster to only consider instance groups in the zone that are prefixed, reducing the number of candidates.
If the prefix is empty, no external instance groups will be used to keep backward compatibility in terms of API calls.

Origin-commit: e29c0b6ce3c068e02419a7b3cbc381b919981f50

… remaining nodes for k8s managed IG

Make sure we don't ensure cluster-managed instance group for a zone that has no more nodes left. Creating am IG for a zone that has no instances causes errors when attaching to backend service.

```
failed to ensure load balancer: googleapi: Error 400: Invalid value for field 'resource.backends[5].group': 'https://www.googleapis.com/compute/v1/projects/openshift-qe/zones/us-central1-c/instanceGroups/k8s-ig--8d8682bc12c7a717'. Instance group must have a network to be attached to a backend service. Add an instance to give the instance group a network., invalid
```

Origin-commit: 3915cef99ee4eedc9755d454abb7e4efa2a63bff

Origin-commit: b992ee2fcb5cd610e9242c3165908b6bc6e423f5

UPSTREAM: <carry>: filter out RBR and SCC paths from OpenAPI

Origin-commit: 5ce9a77a641ec9d0399226af572e429317d3daf6

UPSTREAM: <carry>: filter out RBR and SCC paths from OpenAPI

Origin-commit: 0ee08c7a5e138e8df2bd7d010e9ab59a6543cf63

Origin-commit: 14ba1f8ece9a7bb00ececb2a35b5f8f5fbeacc83

UPSTREAM: <carry>: prevent apiservice registration by CRD controller when delegating

Origin-commit: 3d216eab7adcbd8596606d72d31b6af621bfd350

UPSTREAM: <carry>: prevent CRD registration from fighting with APIServices

Origin-commit: c1c87eeade4730a2271cb98b4c6ea16af07e3e68

UPSTREAM: <carry>: always delegate namespaced resources

Origin-commit: 7f0815b5a88d57046a92fbdbc493bab2ad28a79c

…en it exists

Origin-commit: d3ceac4e065c3d2689192fda102303030cfdb928

Origin-commit: a869af0c97e3d97bddedcd76af8a62da6c879c02

…trap SDN when SDN is down

Origin-commit: 36c5e7d672bf82bd09ee382564bc03ef8e1b3a76

…let logs endpoint

Provide an administrator a streaming view of journal logs without them having
to implement a client side reader. Only available to cluster admins.

Origin-commit: 7331c6412a9ef1b23155d7fd928f4ddc6961a05b

…signer to token controller

:100644 100644 b32534e... 3e694fc... M	pkg/controller/serviceaccount/tokens_controller.go

…ontroller-manager

…rces from quota

…ploymentconfig

…ly to admission plugin

…options

Origin-commit: 33a71aff9bb4e204bf2e15af4cdfb5bd0525ce4e

Origin-commit: 10c14ca7ae63428823e58790c16078d8094e4b95

The feature gate is not yet enabled and may not be for several releases.
Pod team owns allowing this to be used.

Upstream does not verify the apiextensions-apiserver openapi output. We do.

Origin-commit: c59fcc99d1897eda3f16e0cf7a911e6913644b6d

The upstream can't enable this, but we need to do so in order to
properly validate that cluster upgrades retain availability.

Origin-commit: 917e8cb064643370573808e9aba8dbec5df456ff

Origin-commit: 9d5ba9e3f0436231f4eaab665bad2f9906ba746f

Origin-commit: 45f159f05b92c893c175ffe968f89a34f5581f5b

Instead of making a request to Cinder we can read availability
zone name from metadata.

Origin-commit: ae11a2930f11948c5539612ca9177c1567d67207

…aks tests

Origin-commit: 020fcb4398633c83a8877c0c17053e80d400c6b2

… new kubelet delay in pod deletion

Origin-commit: a1d5a1201d5fb4616187cd009f126f5fe7fa0787

Origin-commit: beac12d815b4099cfd4f4d953da4b8789054be51

…ofile

Origin-commit: 84ba7fc304870a30df7136da14bccb4d5232f075

Origin-commit: 4498bb4de03ff3a910fed10bed337ba2fcdf321d

…en checking custom columns (kubectl)

This line is not necessary for our test usage and should not be an
issue in OpenShift (openshift-tests already verifies this correctly).

…y running test

OpenShift uses these function before any test is run and they cause NPE

Origin-commit: 131dbb4770bb3bed0c07d2a6ca0cbe4cba2556bb

This line makes the upgrade log output unreadable and provides
no value during the set of tests it's used in:

```
Jan 12 20:49:25.628: INFO: cluster upgrade is Progressing: Working towards registry.svc.ci.openshift.org/ci-op-jbtg7jjb/release@sha256:144e73d125cce620bdf099be9a85225ade489a95622a70075d264ea3ff79219c: downloading update
Jan 12 20:49:26.692: INFO: Poke("http://a74e3476115ce4d2d817a1e5ea608dad-802917831.us-east-1.elb.amazonaws.com:80/echo?msg=hello"): success
Jan 12 20:49:28.727: INFO: Poke("http://a74e3476115ce4d2d817a1e5ea608dad-802917831.us-east-1.elb.amazonaws.com:80/echo?msg=hello"): success
```

Origin-commit: 1cdf04c0e15b79fad3e3a6ba896ed2bb3df42b78

…o function

Origin-commit: 0d7fb2d769d631054ec9ac0721aee623c96c1001

Origin-commit: cb0b340d0e68c9524fa7fd6277f571b6aa68bf86

The following packages have tests that exceed the default 120s
timeout:

k8s.io/kubernetes/pkg/kubelet/volumemanager/reconciler

 - The tests in this package collectively take longer than 120s.

k8s.io/kubernetes/pkg/volume/csi

 - One of the unit tests has to wait 2 minutes for a timeout to
   validate its failure condition.

…nknown labels