What were you trying to do that didn't work?

Sriov-network-operator configures sriov settings for NICs under it's configured SriovNetworkNodePolicy CRD. However it seems that NM along with nmstate-operator with a NodeNetworkConfigurationPolicy CRD that overlaps with the sriov-network-operator policy in terms of interfaces and specific configurations, would put this common interface under NM management. Then NM state will copy the sriov settings into explicit NM configurations (e.g. nmconnection files). 

However this is undesired for sriov-network-operator because certain sysfs parameters would be in contention. Namely sriov_numvfs and quite possibly others.

The issue is that if the PF (when under NM management) has a deactivating connection, NM will set sriov_numvfs to zero. This causes pods that have SRIOV interfaces connected to them to become without network connectivity. In other cases when vfio-pci driver is bounded to the sriov interfaces, the NIC driver could get into a deadlock.

For OCP, if the PF experiences NM deactivations (e.g. DHCP timing out or losing carrier, etc..)  the SRIOV settings (e.g. sriov_numvfs) shouldn't be touched.

Please provide the package NVR for which bug is seen:

As discussed with Gris, this occurs with the current version of NM.

How reproducible:

Steps to reproduce

https://issues.redhat.com/browse/OCPBUGS-17564
https://issues.redhat.com/browse/OCPBUGS-18430 

Details on the interactions of sriov-network-operator and nmstate-operator are detailed in the above bugs.

This is a severity 1 and 2 customer case issue.

Expected results

Actual results

We need to figure out the best way to solve this issue in k8s upstream. Questions to answer:
1)  Can NM provide a way to turn off managing sriov altogether when sriov-network-operator is installed.
2)  Can sriov-network-operator know about NM and NMState.

 - New dependency on NMState and NM
 - Upstream community, will they be on board adding such a dependency
 - Will we need to support other Network managers other than NM