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

Bug 1729311

Summary: network.config.openshift.io does not make it clear it is read-only
Product: OpenShift Container Platform Reporter: Ben Parees <bparees>
Component: NetworkingAssignee: Alexander Constantinescu <aconstan>
Status: CLOSED ERRATA QA Contact: zhaozhanqi <zzhao>
Severity: low Docs Contact:
Priority: unspecified    
Version: 4.2.0CC: aos-bugs, spadgett
Target Milestone: ---   
Target Release: 4.2.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-10-16 06:33:27 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 Ben Parees 2019-07-11 21:51:53 UTC
Our docs state that the networks config resource should not be edited:


You cannot modify your cluster networking after installation. If you must customize your network, you customize networking during installation.


But the api doc makes it seem like you can:

oc explain network.spec --api-version=config.openshift.io/v1
KIND:     Network
VERSION:  config.openshift.io/v1

RESOURCE: spec <Object>

DESCRIPTION:
     spec holds user settable values for configuration.

FIELDS:
   clusterNetwork	<[]Object>
     IP address pool to use for pod IPs.

   externalIP	<Object>
     externalIP defines configuration for controllers that affect
     Service.ExternalIP

   networkType	<string>
     NetworkType is the plugin that is to be deployed (e.g. OpenShiftSDN). This
     should match a value that the cluster-network-operator understands, or else
     no networking will be installed. Currently supported values are: -
     OpenShiftSDN

   serviceNetwork	<[]string>
     IP address pool for services. Currently, we only support a single entry
     here.


The api doc should make it clear these fields should not be edited (and even better we should also enforce that they are not edited).

Comment 1 Alexander Constantinescu 2019-07-23 12:42:54 UTC
Hi

PR is awaiting code review: https://github.com/openshift/api/pull/381

Best regards,
Alexander

Comment 2 zhaozhanqi 2019-08-23 02:44:35 UTC
*** Bug 1732149 has been marked as a duplicate of this bug. ***

Comment 3 zhaozhanqi 2019-08-23 08:06:22 UTC
Verified this bug on 4.2.0-0.nightly-2019-08-23-004712

#oc explain network.spec --api-version=config.openshift.io/v1
KIND:     Network
VERSION:  config.openshift.io/v1

RESOURCE: spec <Object>

DESCRIPTION:
     spec holds user settable values for configuration. As a general rule, this
     SHOULD NOT be read directly. Instead, you should consume the NetworkStatus,
     as it indicates the currently deployed configuration. Currently, most spec
     fields are immutable after installation. Please view the individual ones
     for further details on each.

FIELDS:
   clusterNetwork	<[]Object>
     IP address pool to use for pod IPs. This field is immutable after
     installation.

   externalIP	<Object>
     externalIP defines configuration for controllers that affect
     Service.ExternalIP

   networkType	<string>
     NetworkType is the plugin that is to be deployed (e.g. OpenShiftSDN). This
     should match a value that the cluster-network-operator understands, or else
     no networking will be installed. Currently supported values are: -
     OpenShiftSDN This field is immutable after installation.

   serviceNetwork	<[]string>
     IP address pool for services. Currently, we only support a single entry
     here. This field is immutable after installation.

Comment 4 errata-xmlrpc 2019-10-16 06:33:27 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-2019:2922