Bug 1807611 - CNO doesn't set status if `networkType` is none in install-config
Summary: CNO doesn't set status if `networkType` is none in install-config
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.5.0
Assignee: Ben Bennett
QA Contact: huirwang
Depends On:
TreeView+ depends on / blocked
Reported: 2020-02-26 17:50 UTC by Vadim Rutkovsky
Modified: 2020-07-13 17:22 UTC (History)
1 user (show)

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
Clone Of:
Last Closed: 2020-07-13 17:21:31 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Github openshift cluster-network-operator pull 506 None closed Bug 1807611: Set network config status even with unknown network plugin 2020-06-23 08:50:56 UTC
Red Hat Product Errata RHBA-2020:2409 None None None 2020-07-13 17:22:05 UTC

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.


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