Bug 2052062

Summary: Whereabouts should implement client-go 1.22+
Product: OpenShift Container Platform Reporter: Douglas Smith <dosmith>
Component: NetworkingAssignee: Miguel Duarte Barroso <mduarted>
Networking sub component: multus QA Contact: Weibin Liang <weliang>
Status: CLOSED ERRATA Docs Contact:
Severity: urgent    
Priority: urgent CC: mduarted, weliang
Version: 4.11   
Target Milestone: ---   
Target Release: 4.10.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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.
 Story Points: ---
Clone Of: 2052055 Environment:
Last Closed: 2022-03-10 16:43:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2052055    
Bug Blocks:    

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: 10.0.156.228
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
sh-4.4#
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.

https://access.redhat.com/errata/RHSA-2022:0056