Bug 1788522 - [library-go] Change default binding network to support dual stack
Summary: [library-go] Change default binding network to support dual stack
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: kube-apiserver
Version: 4.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 4.3.z
Assignee: Stefan Schimanski
QA Contact: Ke Wang
URL:
Whiteboard:
Depends On: 1788521
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-07 12:15 UTC by Michal Fojtik
Modified: 2020-06-03 03:31 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1788521
Environment:
Last Closed: 2020-06-03 03:30:41 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift library-go pull 658 0 None closed Bug 1788522: config: default bind network to tcp instead of tcp4 [release-4.3] 2020-06-10 15:34:04 UTC
Red Hat Product Errata RHBA-2020:2256 0 None None None 2020-06-03 03:31:00 UTC

Description Michal Fojtik 2020-01-07 12:15:44 UTC
+++ This bug was initially created as a clone of Bug #1788521 +++

Description of problem:

We use SetRecommendedServingInfoDefaults() in library-go across all operators to provide defaults for API servers that those operators run to serve metrics and healthz. The current default for binding network is hardcoded to "tcp4" which won't work in IPv6 clusters.


Actual results:

Default is "tcp4"

Expected results:

Default should be "tcp"


Additional info:

--- Additional comment from Michal Fojtik on 2020-01-07 12:15:08 UTC ---

Moving directly to verified as there is nothing for QA to verify until this hits the individual operators.

Comment 5 Ke Wang 2020-01-19 08:52:47 UTC
Verified ENV and steps,
Client Version: v4.3.0
Server Version: 4.3.0-rc.2
Kubernetes Version: v1.16.2

$ master=$(oc get node | grep master | awk '{print $1}' | head -1)
$ oc debug node/$master

After logged in the master debug pod, 
sh-4.2# chroot /host

- check if the field "bindNetwork":"tcp4" have not been changed, found them as below,
# grep -rnw /etc/kubernetes -e '"bindNetwork":"tcp4"' | awk -F: '{print $1}'
/etc/kubernetes/static-pod-resources/kube-apiserver-pod-3/configmaps/config/config.yaml
/etc/kubernetes/static-pod-resources/kube-apiserver-pod-4/configmaps/config/config.yaml
/etc/kubernetes/static-pod-resources/kube-apiserver-pod-6/configmaps/config/config.yaml
/etc/kubernetes/static-pod-resources/kube-apiserver-pod-7/configmaps/config/config.yaml
/etc/kubernetes/static-pod-resources/kube-apiserver-pod-8/configmaps/config/config.yaml
/etc/kubernetes/static-pod-resources/kube-apiserver-pod-9/configmaps/config/config.yaml
/etc/kubernetes/static-pod-resources/kube-apiserver-pod-10/configmaps/config/config.yaml
/etc/kubernetes/static-pod-resources/kube-apiserver-pod-11/configmaps/config/config.yaml

- check if the field "bindNetwork":"tcp" have been changed, found them as below,
# grep -rnw /etc/kubernetes -e '"bindNetwork":"tcp"' | awk -F: '{print $1}'
/etc/kubernetes/static-pod-resources/kube-controller-manager-pod-4/configmaps/cluster-policy-controller-config/config.yaml
/etc/kubernetes/static-pod-resources/kube-controller-manager-pod-6/configmaps/cluster-policy-controller-config/config.yaml
/etc/kubernetes/static-pod-resources/kube-controller-manager-pod-7/configmaps/cluster-policy-controller-config/config.yaml

So I think the fix is not complete for bug.

Comment 6 Stefan Schimanski 2020-05-20 07:49:28 UTC
> Moving directly to verified as there is nothing for QA to verify until this hits the individual operators.

@QE: this is a library fix. It does not change operators. There is nothing to test.

Comment 9 Ke Wang 2020-05-26 04:36:21 UTC
Per https://bugzilla.redhat.com/show_bug.cgi?id=1788522#c6, move the bug verified.

Comment 11 errata-xmlrpc 2020-06-03 03:30:41 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, 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/RHBA-2020:2256


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