Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug 1900630: 4.6: Update from Kubernetes 1.19.0 to 1.19.4 #435

Merged
merged 180 commits into from Nov 25, 2020

Conversation

sttts
Copy link

@sttts sttts commented Nov 3, 2020

This PR updates the base Kubernetes version from 1.19.0 to 1.19.4.

Anago GCB and others added 30 commits August 26, 2020 14:22
…oupsForNLB

Signed-off-by: Pedro Tôrres <t0rr3sp3dr0@gmail.com>
After PR kubernetes#92555, there are a number of gce pd default fs tests skipped. Here the testpatten has SnapshotType set because some provisioning tests use snapshots. But for drivers such as In-tree gce pd driver, the tests will be skipped because of the logic in skipUnsupportedTesthttps://github.com/kubernetes/kubernetes/blob/master/test/e2e/storage/testsuites/base.go#L154
Since multiple drivers might test with the same pattern, so I think we need keep SnapshotType here.

This PR removes the part of the logic in skipUnsupportedTest. This should be ok because all snapshot tests will check whether a driver has snapshot capability or not.
Signed-off-by: knight42 <anonymousknight96@gmail.com>
…-pick-of-#93515-upstream-release-1.19

Automated cherry pick of kubernetes#93515: Use NLB Subnet CIDRs instead of VPC CIDRs in
Signed-off-by: knight42 <anonymousknight96@gmail.com>
Make the yaml valid.
If a pod has a configmap/secret volume an annoying message shows up
in the log approximately every 70 seconds. This happens because the
desiredStateOfWorldPopulator sync loop always call the
MarkRemountRequired. The function finds the volume plugin and check
if the plugin requires mount. Configmap and secret plugins always
returns true for that. Thus, the reconciler code of the volume manager
remounts the volume every time. This commit decrease the log level of
that message in the mount function from warning to V4.

Signed-off-by: José Guilherme Vanz <jguilhermevanz@suse.com>
This reverts commit ebece49936e635f151fdd8a64fa2b77fd183e817.
If a pod has a configmap/secret volume an annoying message shows up
in the log approximately every 70 seconds. This happens because the
desiredStateOfWorldPopulator sync loop always call the
MarkRemountRequired. The function finds the volume plugin and check
if the plugin requires mount. Configmap and secret plugins always
returns true for that. Thus, the reconciler code of the volume manager
remounts the volume every time. This commit change the SetVolumeOwnership
to print the warning only if the function does not finish within 30
seconds.

Signed-off-by: José Guilherme Vanz <jguilhermevanz@suse.com>
Currently if a group is specified for an impersonated user,
'system:authenticated' is not added to the 'Groups' list inside the
request context.
This causes priority and fairness match to fail. The catch-all flow
schema needs the user to be in the 'system:authenticated' or in the
'system:unauthenticated' group. An impersonated user with a specified
group is in neither.

As a general rule, if an impersonated user has passed authorization
checks, we should consider him authenticated.
A bug was discovered in the `enforceRequirements` func for `upgrade plan`.
If a command line argument that specifies the target Kubernetes version is
supplied, the returned `ClusterConfiguration` by `enforceRequirements` will
have its `KubernetesVersion` field set to the new version.
If no version was specified, the returned `KubernetesVersion` points to the
currently installed one.

This remained undetected for a couple of reasons
- It's only `upgrade plan` that allows for the version command line argument to
  be optional (in `upgrade plan` it's mandatory)
- Prior to 1.19, the implementation of `upgrade plan` did not make use of the
  `KubernetesVersion` returned by `enforceRequirements`.

`upgrade plan` supports this optional command line argument to enable
air-gapped setups (as not specifying a version on the command line will end up
looking for the latest version over the Interned).

Hence, the only option is to make `enforceRequirements` consistent in the
`upgrade plan` case and always return the currently installed version in the
`KubernetesVersion` field.

Signed-off-by: Rostislav M. Georgiev <rostislavg@vmware.com>
Pinning the kube-controller-manager and kube-scheduler kubeconfig files
to point to the control-plane-endpoint can be problematic during
immutable upgrades if one of these components ends up contacting an N-1
kube-apiserver:
https://kubernetes.io/docs/setup/release/version-skew-policy/#kube-controller-manager-kube-scheduler-and-cloud-controller-manager
For example, the components can send a request for a non-existing API
version.

Instead of using the CPE for these components, use the LocalAPIEndpoint.
This guarantees that the components would talk to the local
kube-apiserver, which should be the same version, unless the user
explicitly patched manifests.
…ick-of-#94398-origin-release-1.19

Automated cherry pick of kubernetes#94398: kubeadm: make the scheduler and KCM connect to local endpoint
…-pick-of-#94261-upstream-release-1.19

Add PR kubernetes#89069 Action Required to 1.19 release notes
…-of-#93646-origin-release-1.19

Automated cherry pick of kubernetes#93646: let panics propagate up when processLoop panic
Change-Id: I30005efec519840142bc7151aeaa543912a2f84b
…ck-of-#94246-upstream-release-1.19

Automated cherry pick of kubernetes#94246: Fix issue on skipTest in storage suits
…ck-of-#94316-upstream-release-1.19

Automated cherry pick of kubernetes#94316: Fixed reflector not recovering from "Too large resource
The isCoreDNSVersionSupported() check assumes that
there is a running kubelet, that manages the CoreDNS containers.

If the containers are being created it is not possible to fetch
their image digest. To workaround that, a poll can be used in
isCoreDNSVersionSupported() and wait for the CoreDNS Pods
are expected to be running. Depending on timing and CNI
yet to be installed this can cause problems related to
addon idempotency of "kubeadm init", because if the CoreDNS
Pods are waiting for another step they will never get running.

Remove the function isCoreDNSVersionSupported() and assume that
the version is always supported. Rely on the Corefile migration
library to error out if it must.
…-pick-of-#94294-upstream-release-1.19

Automated cherry pick of kubernetes#94294: Remove duplicate nodeSelector
…ck-of-#94306-upstream-release-1.19

Automated cherry pick of kubernetes#94306: fix(azure): check error returned by scaleSet.getVMSS
…ck-of-#93773-upstream-release-1.19

Automated cherry pick of kubernetes#93773: fix(kubelet): protect `containerCleanupInfos` from concurrent map writes
…of-#94421-upstream-release-1.19

Automated cherry pick of kubernetes#94421: kubeadm: Fix `upgrade plan` for air-gapped setups
…k-of-#94204-upstream-release-1.19

Automated cherry pick of kubernetes#94204: Add impersonated user to system:authenticated group
@openshift-ci-robot
Copy link

@tnozicka: tnozicka unauthorized: /override is restricted to Repo administrators, approvers in top level OWNERS file.

In response to this:

These do not look like flakes, at least verify-commits seems persistent but feel free to clear the hold if I'm wrong.
rebase will never pass verify-commits by nature
/override verify-commits

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.

@sttts sttts changed the title Bug 1900579: 4.6: Update from Kubernetes 1.19.0 to 1.19.4 Bug 1900630: 4.6: Update from Kubernetes 1.19.0 to 1.19.4 Nov 23, 2020
@openshift-ci-robot
Copy link

@sttts: This pull request references Bugzilla bug 1900630, which is invalid:

  • expected the bug to target the "4.6.z" release, but it targets "---" instead
  • expected Bugzilla bug 1900630 to depend on a bug targeting a release in 4.7.0 and in one of the following states: VERIFIED, RELEASE_PENDING, CLOSED (ERRATA), but no dependents were found

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

Bug 1900630: 4.6: Update from Kubernetes 1.19.0 to 1.19.4

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.

@mfojtik mfojtik added bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. and removed bugzilla/invalid-bug Indicates that a referenced Bugzilla bug is invalid for the branch this PR is targeting. labels Nov 23, 2020
@mfojtik
Copy link
Member

mfojtik commented Nov 23, 2020

/hold cancel

overriding valid-bug as this is minor kubernetes update that won't have equivalent in master branch. this is described in patch manager doc as exception.

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 23, 2020
@mfojtik
Copy link
Member

mfojtik commented Nov 23, 2020

/override ci/prow/verify-commits

@openshift-ci-robot
Copy link

@mfojtik: Overrode contexts on behalf of mfojtik: ci/prow/verify-commits

In response to this:

/override ci/prow/verify-commits

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.

@openshift-ci-robot openshift-ci-robot removed the bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. label Nov 23, 2020
@openshift-ci-robot
Copy link

@sttts: This pull request references Bugzilla bug 1900630, which is invalid:

  • expected the bug to target the "4.6.z" release, but it targets "---" instead
  • expected Bugzilla bug 1900630 to depend on a bug targeting a release in 4.7.0 and in one of the following states: VERIFIED, RELEASE_PENDING, CLOSED (ERRATA), but no dependents were found

Comment /bugzilla refresh to re-evaluate validity if changes to the Bugzilla bug are made, or edit the title of this pull request to link to a different bug.

In response to this:

Bug 1900630: 4.6: Update from Kubernetes 1.19.0 to 1.19.4

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.

@openshift-ci-robot openshift-ci-robot added the bugzilla/invalid-bug Indicates that a referenced Bugzilla bug is invalid for the branch this PR is targeting. label Nov 23, 2020
@mfojtik mfojtik added bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. and removed bugzilla/invalid-bug Indicates that a referenced Bugzilla bug is invalid for the branch this PR is targeting. labels Nov 23, 2020
@mfojtik
Copy link
Member

mfojtik commented Nov 23, 2020

/hold until merge window for 4.6.z open

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 23, 2020
@mfojtik mfojtik added the cherry-pick-approved Indicates a cherry-pick PR into a release branch has been approved by the release branch manager. label Nov 23, 2020
@sdodson sdodson removed the cherry-pick-approved Indicates a cherry-pick PR into a release branch has been approved by the release branch manager. label Nov 23, 2020
@sdodson
Copy link
Member

sdodson commented Nov 23, 2020

Discussed on slack that we'd remove cherry-pick-approved until the merge window opens.

@mfojtik mfojtik added cherry-pick-approved Indicates a cherry-pick PR into a release branch has been approved by the release branch manager. and removed do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. labels Nov 25, 2020
@mfojtik
Copy link
Member

mfojtik commented Nov 25, 2020

/override ci/prow/verify-commits

@openshift-ci-robot
Copy link

@mfojtik: Overrode contexts on behalf of mfojtik: ci/prow/verify-commits

In response to this:

/override ci/prow/verify-commits

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.

@openshift-bot
Copy link

/retest

Please review the full test history for this PR and help us cut down flakes.

@mfojtik
Copy link
Member

mfojtik commented Nov 25, 2020

/retest

@mfojtik
Copy link
Member

mfojtik commented Nov 25, 2020

/override ci/prow/e2e-aws-ovn

This won't pass without quay.io and it was green before. The test is very flaky and OVN team will be notified to de-flake it. The kube bump certainly does not cause this flakiness.

@openshift-ci-robot
Copy link

@mfojtik: Overrode contexts on behalf of mfojtik: ci/prow/e2e-aws-ovn

In response to this:

/override ci/prow/e2e-aws-ovn

This won't pass without quay.io and it was green before. The test is very flaky and OVN team will be notified to de-flake it. The kube bump certainly does not cause this flakiness.

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.

@openshift-merge-robot openshift-merge-robot merged commit b1ff88f into openshift:release-4.6 Nov 25, 2020
@openshift-ci-robot
Copy link

@sttts: All pull requests linked via external trackers have merged:

Bugzilla bug 1900630 has been moved to the MODIFIED state.

In response to this:

Bug 1900630: 4.6: Update from Kubernetes 1.19.0 to 1.19.4

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. bugzilla/severity-high Referenced Bugzilla bug's severity is high for the branch this PR is targeting. bugzilla/valid-bug Indicates that a referenced Bugzilla bug is valid for the branch this PR is targeting. cherry-pick-approved Indicates a cherry-pick PR into a release branch has been approved by the release branch manager. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet