Bug 1807611

Summary:	CNO doesn't set status if `networkType` is none in install-config
Product:	OpenShift Container Platform	Reporter:	Vadim Rutkovsky <vrutkovs>
Component:	Networking	Assignee:	Ben Bennett <bbennett>
Networking sub component:	openshift-sdn	QA Contact:	huirwang
Status:	CLOSED ERRATA	Docs Contact:
Severity:	unspecified
Priority:	unspecified	CC:	danw
Version:	4.4
Target Milestone:	---
Target Release:	4.5.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:	Cause: A code change inadvertently stopped setting the status for third-party plugins Consequence: The CNO status never indicated that it was working Fix: Add back code to set the status when a third-party plugin is in use Result: CNO correctly reports status when a third-party plugin is in use	Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-07-13 17:21:31 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 Vadim Rutkovsky 2020-02-26 17:50:23 UTC

Description of problem:
CNO creates network.config.openshift.io/version object with network information, however it won't set `status` for it if install-config has CNO unmanaged (`networking.networkType: none`)

cluster-etcd-operator uses `status.serviceNetwork` from that object to find out the preferred IP address family to use. As a result, in 4.4 any non-CNO network deployed with user manifests (e.g. Calico) would make CEO loop with "networks.%s/cluster: status.serviceNetwork not found" messages

CNO should copy the `spec` to `status` if its being set to unmanaged.

Comment 1 Dan Winship 2020-02-26 19:32:58 UTC

So apparently we used to do this and then intentionally stopped in https://github.com/openshift/cluster-network-operator/pull/111. There's no explanation of why there, but I remember some discussion about the idea that if you were using another network plugin that CNO doesn't understand, then it should let that other plugin set the network config status.

eg, in particular, the other plugin might only support a single ClusterNetwork, in which case if you tried to configure multiple ClusterNetwork values in the config, it would only copy the first one to the status. (But AFAIK there are no actual third-party network operators/plugins that actually set the config status.)

OTOH, what is supported for serviceNetwork is really determined by kubernetes, not by the network plugin. So it might make sense for CNO to set that itself...

Comment 6 errata-xmlrpc 2020-07-13 17:21:31 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:2409