Bug 2052062 - Whereabouts should implement client-go 1.22+
Summary: Whereabouts should implement client-go 1.22+
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.11
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.10.0
Assignee: Miguel Duarte Barroso
QA Contact: Weibin Liang
Depends On: 2052055
TreeView+ depends on / blocked
Reported: 2022-02-08 15:40 UTC by Douglas Smith
Modified: 2022-03-10 16:44 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Client-go < 1.22 does not have a sufficient technique for retrying requests to the Kubernetes API Consequence: Retries to the Kubernetes API were not sufficient. Fix: Implement client-go 1.22. Result: Retries are attempted.
Clone Of: 2052055
Last Closed: 2022-03-10 16:43:51 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift whereabouts-cni pull 83 0 None open Bug 2052062: client-go bump to v1.22 [backport 4.10] 2022-02-08 17:52:09 UTC
Red Hat Product Errata RHSA-2022:0056 0 None None None 2022-03-10 16:44:04 UTC

Description Douglas Smith 2022-02-08 15:40:38 UTC
+++ This bug was initially created as a clone of Bug #2052055 +++

Description of problem: Client-go 1.22+ includes fixes for retries against the API server. While client-go 1.23 is preferable, 1.22 has the fixes we're looking for.

Version-Release number of selected component (if applicable): (all)

How reproducible: The primary problems are reproducible in CI during upgrades, specifically when the SDN is upgrading, this appears in an unacceptable percentage of runs.

Steps to verify: Presence of client-go 1.22 in go.mod & no regressions.

Comment 4 Weibin Liang 2022-02-10 21:03:22 UTC
Tested and verified in 4.10.0-0.nightly-2022-02-10-062935

[weliang@weliang ~]$ oc get clusterversion
NAME      VERSION                              AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.10.0-0.nightly-2022-02-10-062935   True        False         54m     Cluster version is 4.10.0-0.nightly-2022-02-10-062935
[weliang@weliang ~]$ oc get node
NAME                                         STATUS   ROLES    AGE   VERSION
ip-10-0-144-18.us-east-2.compute.internal    Ready    master   79m   v1.23.3+759c22b
ip-10-0-156-228.us-east-2.compute.internal   Ready    worker   71m   v1.23.3+759c22b
ip-10-0-173-106.us-east-2.compute.internal   Ready    worker   71m   v1.23.3+759c22b
ip-10-0-179-57.us-east-2.compute.internal    Ready    master   77m   v1.23.3+759c22b
ip-10-0-202-181.us-east-2.compute.internal   Ready    worker   67m   v1.23.3+759c22b
ip-10-0-223-39.us-east-2.compute.internal    Ready    master   78m   v1.23.3+759c22b
[weliang@weliang ~]$ oc debug node/ip-10-0-156-228.us-east-2.compute.internal
Starting pod/ip-10-0-156-228us-east-2computeinternal-debug ...
To use host binaries, run `chroot /host`
chroot /hostPod IP:
If you don't see a command prompt, try pressing enter.
sh-4.4# chroot /host
sh-4.4# cat /var/lib/cni/bin/whereabouts | grep -i "0\.22\.6"
Binary file (standard input) matches

Comment 7 errata-xmlrpc 2022-03-10 16:43:51 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.10.3 security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.