Update k8s client libs to v0.32.2

[theobarberbany]

No description provided.

[k8s-ci-robot]

This issue is currently awaiting triage.

If the repository mantainers determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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-sigs/prow repository.

[k8s-ci-robot]

Welcome @theobarberbany!

It looks like this is your first PR to kubernetes/cloud-provider-gcp 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes/cloud-provider-gcp has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @theobarberbany. Thanks for your PR.

I'm waiting for a kubernetes 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-sigs/prow repository.

[theobarberbany]

Ah - Will work through https://github.com/kubernetes/cloud-provider-gcp/blob/master/docs/instruction-how-to-bump-repository.md and update.

[mmamczur]

Hello @theobarberbany, thank you for the PR!

could you also extend this with points 1-3 from here https://github.com/kubernetes/cloud-provider-gcp/blob/master/docs/instruction-how-to-bump-repository.md?

specifically the version in ginko-test-package-version.env
and the sha sums in WORKSPACE, best to use tools/sha256_generator.sh for this

don't do the cluster/ directory sync, we can follow up with that later

[theobarberbany]

Heya @mmamczur. I've updated the PR with changes for points 1-3. ./tools/verify-all.sh is green locally for me as well.

[mmamczur]

/ok-to-test

[mmamczur]

/retest

[theobarberbany]

Hmm, looks like the cloud controller manager is failing to come up on the master. Logs

I0218 10:17:49.396967      12 serving.go:386] Generated self-signed cert in-memory
I0218 10:17:50.611408      12 serving.go:386] Generated self-signed cert in-memory
W0218 10:17:53.239804      12 requestheader_controller.go:196] Unable to get configmap/extension-apiserver-authentication in kube-system.  Usually fixed by 'kubectl create rolebinding -n kube-system ROLEBINDING_NAME --role=extension-apiserver-authentication-reader --serviceaccount=YOUR_NS:YOUR_SA'
unable to load configmap based request-header-client-ca-file: configmaps "extension-apiserver-authentication" is forbidden: User "system:cloud-controller-manager" cannot get resource "configmaps" in API group "" in the namespace "kube-system"
Error: unable to load configmap based request-header-client-ca-file: configmaps "extension-apiserver-authentication" is forbidden: User "system:cloud-controller-manager" cannot get resource "configmaps" in API group "" in the namespace "kube-system"
Usage:
  cloud-controller-manager [flags]
  ..... [ cloud-controller-manager usage flags]
.....

kubelet on node:

08 bootstrap.go:120] "Using bootstrap kubeconfig to generate TLS client cert, key and kubeconfig file"
Feb 18 10:52:55.282707 kt2-15e4deb8-db2b-minion-group-8bkb kubelet[6308]: I0218 10:52:55.282662    6308 cert_rotation.go:140] Starting client certificate rotation controller
Feb 18 10:52:55.283267 kt2-15e4deb8-db2b-minion-group-8bkb kubelet[6308]: I0218 10:52:55.283230    6308 bootstrap.go:151] "No valid private key and/or certificate found, reusing existing private key or creating a new one"
Feb 18 10:52:55.297452 kt2-15e4deb8-db2b-minion-group-8bkb kubelet[6308]: E0218 10:52:55.297388    6308 run.go:72] "command failed" err="failed to run Kubelet: cannot create certificate signing request: certificatesigningrequests.certificates.k8s.io is forbidden: User \"kubelet\" cannot create resource \"certificatesigningrequests\" in API group \"certificates.k8s.io\" at the cluster scope"
Feb 18 10:52:55.300651 kt2-15e4deb8-db2b-minion-group-8bkb systemd[1]: kubelet.service: Main process exited, code=exited, status=1/FAILURE
Feb 18 10:52:55.300840 kt2-15e4deb8-db2b-minion-group-8bkb systemd[1]: kubelet.service: Failed with result 'exit-code'.

I'm not sure where this RBAC change may have come from, will look at changelogs.

[theobarberbany]

/test cloud-provider-gcp-e2e-full

[theobarberbany]

Also found this error in the kube-controller-manager logs:

E0218 16:28:28.973071      12 run.go:72] "command failed" err="built-in cloud providers are disabled. The ipam CloudAllocator is not available"

And we're setting: I0218 15:56:47.548575 12 flags.go:64] FLAG: --cidr-allocator-type="CloudAllocator"

It looks like it was removed in this PR kubernetes/kubernetes#128197 (cc @aojea) and some similar config change may hae been required?

[YifeiZhuang]

@mmamczur should we do a branch cut before merging this PR? Otherwise 1.31 will be missing and directly goes to 1.32

[mmamczur]

@mmamczur should we do a branch cut before merging this PR? Otherwise 1.31 will be missing and directly goes to 1.32

I created it already https://github.com/kubernetes/cloud-provider-gcp/tree/release-1.31

Iteresting, I see that now the e2e-full passed, let's retrigger since kops failure looks like a flake

/retest

[mmamczur]

actually, we should try updating that cluster/ dir first, I think it has the change you mentioned
I created a temp PR #803 with a commit added on top of this one, let's see if it passes

[theobarberbany]

For #803, it looks like it's mostly passing? Just a single failure.

Is the approach of disabling KUBE_GCE_ENABLE_IP_ALIASES not the right way forward here?

[mmamczur]

ok, it passed now.

@theobarberbany if you'd like to use your PR then could you cherrypick (or you could probably just fast forward since it is based on your commits) this commit 14c5bdc on your changes? (and remove the one that does test disabling KUBE_GCE_ENABLE_IP_ALIASES)

it's best if we don't touch that config variable

the thing with this cluster/ directory is that it has to be kept in sync with https://github.com/kubernetes/kubernetes/tree/master/cluster on the appropriate version. So it's a copy but not exact. There were changes related to that alias stuff in k/k so resyncing it fixed the issue. In any case the process to update that directory is super annoying.

[theobarberbany]

Ok great, I've updated :)

Also that is very annoying, but good to know!

[mmamczur]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mmamczur, theobarberbany

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

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [mmamczur]

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