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.
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):
Steps to Reproduce:
1. Setup cluster with multus enabled
2. Set the multus.conf as above
The multus will read the network-attachment-defination from kube-system namespace.
Should read them from the `multus` namespace.
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).
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.