Description of problem: When set the multus config to use clusterNetwork or defaultNetworks, it will read the net-attach-def which created under kube-system. See https://github.com/openshift/ose-multus-cni/blob/release/k8sclient/k8sclient.go#L542 { "name": "multus-cni-network", "type": "multus", "logFile": "/var/log/multus.log", "logLevel": "debug", "clusterNetwork": "openshift-sdn", "defaultNetworks": ["macvlan"], "kubeconfig": "/etc/cni/net.d/multus.d/multus.kubeconfig" } In 4.0 installation, the operator will create a separated namespace called `multus` and all the multus related resources will be created there. So we should also read the CRDs from this namespace instead of kube-system Version-Release number of selected component (if applicable): 4.0 How reproducible: always Steps to Reproduce: 1. Setup cluster with multus enabled 2. Set the multus.conf as above 3. Actual results: The multus will read the network-attachment-defination from kube-system namespace. Expected results: Should read them from the `multus` namespace. Additional info:
Hi Bo, With network-cluster-operator, the expected behavior may change. Let me check the expected behavior and reply back to you.
Hey Tomo - shouldn't these be cluster-scoped?
Casey, the CRD object (for defaultNetwork/clusterNetwork) should be cluster-scoped because clusterNetwork is used for 'network for cluster' (as it is). At upstream (github.com/intel), we define 'kube-system' can be the namespace for admin, but OCP4 uses another namespace for multus, so we need to change the code to support non 'kube-system', I guess. I am in double checking and let you know the details next week (Mon/Tue timeframe).
https://github.com/intel/multus-cni/issues/252
Looks like the fixes for this are in place (and available downstream), the fixes were created in this (since merged) pull request: https://github.com/intel/multus-cni/pull/254
Both the systemNamespaces and multusNamespace are working well on 4.0.0-0.nightly-2019-04-10-182914 with disable the CVO and network operator. Verify this bug.
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:0758