Bump to kubernetes-v1.18.0-rc.1 #118
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…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
…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
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.
openshift-ci-robot
added
the
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: marun The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci-robot
added
area/dependency
marun
changed the base branch from
oc-4.5-kubernetes-1.18.0-beta.2
to
origin-4.5-kubernetes-1.18.0-rc.1
marun
changed the title
openshift-ci-robot
removed
the
do-not-merge/work-in-progress
3 tasks
marun
force-pushed
the
origin-4.5-kubernetes-v1.18.0-rc.1
branch
from
aaae410
to
ade9531
Compare
|
@marun: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Only change from #116 is the dropping of 606dcdd due to kubernetes#89078 removing the targeted test.