Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1707239

Summary:	[DOCS] Incorrect step for check the updated configuration for network operator CR
Product:	OpenShift Container Platform	Reporter:	zhaozhanqi <zzhao>
Component:	Documentation	Assignee:	Jason Boxman <jboxman>
Status:	CLOSED CURRENTRELEASE	QA Contact:	zhaozhanqi <zzhao>
Severity:	medium	Docs Contact:	Vikram Goyal <vigoyal>
Priority:	high
Version:	4.1.0	CC:	anusaxen, aos-bugs, jokerman, mmccomas
Target Milestone:	---
Target Release:	4.1.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-05-22 20:47:54 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description zhaozhanqi 2019-05-07 06:46:59 UTC

Document URL: 

https://docs.openshift.com/container-platform/4.1/networking/configuring-network-operator.html#network-modifying-config-configuring-network-operator

Section Number and Name: 

Run the following command to confirm that the Network Operator accepted the updated configuration:

Describe the issue: 
When updated the network operator CR, I don't think the following command can check the config if had been take effect.

****************************************
Run the following command to confirm that the Network Operator accepted the updated configuration:

$ oc get clusteroperator network
NAME      VERSION     AVAILABLE   PROGRESSING   FAILING   SINCE
network   4.0.0-0.9   True        False         False     1m
****************************************

Suggestions for improvement: 

I think we should use `oc get networks.operator.openshift.io -o yaml` to check

Additional information:

Comment 1 Jason Boxman 2019-05-07 18:46:42 UTC

Hi!

Do you know what the output for the command `oc get networks.operator.openshift.io -o yaml` is?

Thanks!

Comment 2 Anurag saxena 2019-05-07 20:07:08 UTC

(In reply to Jason Boxman from comment #1)
> Hi!
> 
> Do you know what the output for the command `oc get
> networks.operator.openshift.io -o yaml` is?
> 
> Thanks!

# oc get networks.operator.openshift.io -o yaml
apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: Network
  metadata:
    creationTimestamp: 2019-05-07T02:36:49Z
    generation: 1
    name: cluster
    resourceVersion: "965"
    selfLink: /apis/operator.openshift.io/v1/networks/cluster
    uid: f745fc88-7070-11e9-b977-801844eef6b8
  spec:
    clusterNetwork:
    - cidr: 10.128.0.0/14
      hostPrefix: 23
    defaultNetwork:
      type: OpenShiftSDN
    serviceNetwork:
    - 172.30.0.0/16
  status: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

The change in configurations should be reflected here if taken successfully.

`oc get clusteroperator network` is also acceptable step which will eventually show the FAILING as true if CR is badly configured but agree that `oc get networks.operator.openshift.io -o yaml` would be a great representation in this case

Comment 3 Jason Boxman 2019-05-09 00:08:42 UTC

I've created a PR[0] with the proposed change. Can you take a look? Thanks!

[0] https://github.com/openshift/openshift-docs/pull/14768

Comment 4 zhaozhanqi 2019-05-09 02:32:48 UTC

(In reply to Jason Boxman from comment #3)
> I've created a PR[0] with the proposed change. Can you take a look? Thanks!
> 
> [0] https://github.com/openshift/openshift-docs/pull/14768

the output is not correct since it did not add the new added parameters. you can update to :

$ oc get networks.operator.openshift.io -o yaml
apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: Network
  metadata:
    creationTimestamp: "2019-05-08T03:34:32Z"
    generation: 2
    name: cluster
    resourceVersion: "497579"
    selfLink: /apis/operator.openshift.io/v1/networks/cluster
    uid: 31c8c3d2-7142-11e9-b77d-801844eef6b8
  spec:
    clusterNetwork:
    - cidr: 10.128.0.0/14
      hostPrefix: 23
    defaultNetwork:
      type: OpenShiftSDN
    deployKubeProxy: false
    kubeProxyConfig:
      bindAddress: 0.0.0.0
      iptablesSyncPeriod: 30s
    serviceNetwork:
    - 172.30.0.0/16
  status: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Comment 5 Jason Boxman 2019-05-09 18:19:33 UTC

I've updated the PR[0] with the correct output.

Thanks!

[0] https://github.com/openshift/openshift-docs/pull/14768

Comment 6 Jason Boxman 2019-05-14 15:02:36 UTC

Hi!

I updated the PR. Can you take a look? Thanks!

https://github.com/openshift/openshift-docs/pull/14768

Comment 7 zhaozhanqi 2019-05-16 02:21:39 UTC

hi, I added the comments the above PR, please review, thanks.

Comment 8 Jason Boxman 2019-05-16 18:06:32 UTC

I've rewritten the content related to this bug. It now explicitly covers configuring Kubernetes network proxy. I've created a new PR for the updated content, and applied the changes from this bug in that PR in several new commits[1][2][3].

I apologize for any confusion on this.

Thanks!

[0] https://github.com/openshift/openshift-docs/pull/14705
[1] https://github.com/openshift/openshift-docs/commit/7dc72de2997a128a42b517387911747a8de5659b
[2] https://github.com/openshift/openshift-docs/pull/14705/commits/108ff7707c5466ad779f15449f690d9df4567203
[3] https://github.com/openshift/openshift-docs/pull/14705/commits/99fe79c80e28c22548be872900da0a91eda2d550#diff-aa18f585abf36ad1ce20fa54f13f153eR49

Comment 9 zhaozhanqi 2019-05-17 06:25:06 UTC

Added comments in the docs. I think we'd better only keep the following in the docs for now.
`
  kubeProxyConfig:
   iptablesSyncPeriod: 30s
`

Comment 10 Jason Boxman 2019-05-20 18:05:53 UTC

I've removed the other parameters. I kept `iptables-min-sync-period` due to this comment[0].

Thanks.

[0] https://github.com/openshift/openshift-docs/pull/14705#discussion_r284692329

Comment 11 zhaozhanqi 2019-05-21 02:20:49 UTC

ok, LGTM, verified this bug.

Comment 12 Jason Boxman 2019-05-21 02:25:53 UTC

Thank you!