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:	Networking	Assignee:	Tomofumi Hayashi <tohayash>
Status:	CLOSED ERRATA	QA Contact:	Meng Bo <bmeng>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.1.0	CC:	aos-bugs, cdc, dosmith, tohayash
Target Milestone:	---
Target Release:	4.1.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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):
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:

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

https://github.com/intel/multus-cni/issues/252

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.

https://access.redhat.com/errata/RHBA-2019:0758