Bug 1669455

Summary: [SDN-131] Multus should read the CRD for clusterNetwork and defaultNetworks from multus namespace instead of kube-system namespace
Product: OpenShift Container Platform Reporter: Meng Bo <bmeng>
Component: NetworkingAssignee: Tomofumi Hayashi <tohayash>
Status: CLOSED ERRATA QA Contact: Meng Bo <bmeng>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.1.0CC: aos-bugs, cdc, dosmith, tohayash
Target Milestone: ---   
Target Release: 4.1.0   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-06-04 10:42:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Meng Bo 2019-01-25 10:48:55 UTC
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):

How reproducible:

Steps to Reproduce:
1. Setup cluster with multus enabled
2. Set the multus.conf as above

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:

Comment 1 Tomofumi Hayashi 2019-01-25 12:01:24 UTC
Hi Bo,

With network-cluster-operator, the expected behavior may change.
Let me check the expected behavior and reply back to you.

Comment 2 Casey Callendrello 2019-01-25 15:16:22 UTC
Hey Tomo - shouldn't these be cluster-scoped?

Comment 3 Tomofumi Hayashi 2019-01-25 15:20:45 UTC
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).

Comment 4 Tomofumi Hayashi 2019-01-29 09:37:07 UTC

Comment 6 Douglas Smith 2019-04-08 18:39:52 UTC
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

Comment 8 Meng Bo 2019-04-11 09:34:02 UTC
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.

Comment 10 errata-xmlrpc 2019-06-04 10:42:15 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.