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.
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...
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