Bug 1729311 - network.config.openshift.io does not make it clear it is read-only
Summary: network.config.openshift.io does not make it clear it is read-only
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: 4.2.0
Assignee: Alexander Constantinescu
QA Contact: zhaozhanqi
URL:
Whiteboard:
: 1732149 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-11 21:51 UTC by Ben Parees
Modified: 2019-10-16 06:33 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-16 06:33:27 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:2922 0 None None None 2019-10-16 06:33:39 UTC

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


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