✨ Update dependencies to Kubernetes v1.16.4

[ialidzhikov]

Bump dependencies for Kubernetes 1.16.4.

[k8s-ci-robot]

Hi @ialidzhikov. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ialidzhikov
To complete the pull request process, please assign pwittrock
You can assign the PR to them by writing /assign @pwittrock in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[munnerz]

/ok-to-test

[ialidzhikov]

I suspect this cherry-pick to 1.16.1 - kubernetes/kubernetes#82618.
PollUntil is replaced with PollImmediateUntil and looks like the cache_test is relying on this 100 millis sleep. If add it before each WaitForCacheSync invocation the tests pass. 😕

/help

[gerred]

/retest

[gerred]

@ialidzhikov will you fix the merge conflicts here? thank you!

[k8s-ci-robot]

@ialidzhikov: The following test failed, say /retest to rerun all failed tests:

Test name	Commit	Details	Rerun command
pull-controller-runtime-test	a0a2255	link	/test pull-controller-runtime-test

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.

[gerred]

@ialidzhikov would you fix the merge conflict here and I will kick off a retest?

Also, would it make sense to instead go to 1.17.1 here?

[vincepri]

Not sure when the next controller-runtime release is, but I'd consider updating and releasing for 1.16 first, the updated kubebuilder tools just landed a few weeks ago, so we should be good for testing

[vincepri]

/retitle ✨ Update dependencies to Kubernetes v1.16.4

[vincepri]

@ialidzhikov Are you able to rebase?

[gerred]

@vincepri 👍 that sgtm, then we'll work toward a 1.17 deps version. I definitely want to get better about having more timely dependency updates with Kubernetes releases (maybe in a pre-release setting). I think we could build some automation a la dependabot to potentially help us here so it's not a massive, manual resolution every time we go to do this.

[ialidzhikov]

I will rebase later today but as I described there is a test failure #732 (comment). I will need to check whether the test needs to be adapted or something else.
Feel free to propose a new PR about it if you have the resolution and the tests passing.

@munnerz, what was your proposal here? To do the time.Sleep patch as in cert-manager/cert-manager@fdce8c6 ?

[vincepri]

@ialidzhikov Unfortunately I can't see the test failure because of the rebase, but as soon as that's done, I can take a look!

[ialidzhikov]

Ha, the tests now passed. Looks like the failing test was fixed with #755.

[vincepri]

/lgtm

/assign @gerred @DirectXMan12

[ialidzhikov]

ping @gerred @DirectXMan12

[vincepri]

@ialidzhikov Given that #754 is already in the milestone and based on a newer version, would it be ok to close this PR in favor of that one?

[ialidzhikov]

@ialidzhikov Given that #754 is already in the milestone and based on a newer version, would it be ok to close this PR in favor of that one?

If the next minor release is planned to be a breaking one, then I am fine to close this PR.

[gerred]

@DirectXMan12 what's your feelings here? I was going to get this PR in in the thoughts we were going to cut a 1.16.x release.

[DirectXMan12]

If folks are super-interested, we can probably re-target this to a stable branch. Otherwise, due to timing, I think it prob makes sense just to go for 1.17 for the next release.

[ialidzhikov]

Closing in favour of #789 or #754.