Bug 1669455 - [SDN-131] Multus should read the CRD for clusterNetwork and defaultNetworks from multus namespace instead of kube-system namespace
Summary: [SDN-131] Multus should read the CRD for clusterNetwork and defaultNetworks f...
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Networking
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.1.0
Assignee: Tomofumi Hayashi
QA Contact: Meng Bo
Depends On:
TreeView+ depends on / blocked
Reported: 2019-01-25 10:48 UTC by Meng Bo
Modified: 2019-06-04 10:42 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Last Closed: 2019-06-04 10:42:15 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:0758 0 None None None 2019-06-04 10:42:22 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.