Hide Forgot
Description of problem: Currently, if we define the net-attach-def in additionalNetwork during installation. It will create the cr in the "default" namespace by hardcoded. And the namespaceIsolation is enabled by default. That means the cr defined in additionalNetwork is hardly be used. We should put the net-attach-def in the multusNamespace which introduced in https://github.com/intel/multus-cni/pull/254 Version-Release number of selected component (if applicable): v4.0.0-0.177.0 How reproducible: always Steps to Reproduce: 1. Setup OCP cluster with the following networkconfig.networkoperator.openshift.io apiVersion: networkoperator.openshift.io/v1 kind: NetworkConfig metadata: name: default spec: additionalNetworks: - name: macvlan-conf rawCNIConfig: '{ "type": "macvlan", "name": "macvlan-network", "master": "eth0", "ipam": { "type": "host-local", "subnet": "10.200.1.0/24", "routes": [{ "dst": "0.0.0.0/0" }], "gateway": "10.200.1.1" } }' type: Raw clusterNetworks: - cidr: 10.128.0.0/14 hostSubnetLength: 9 defaultNetwork: openshiftSDNConfig: mode: NetworkPolicy type: OpenShiftSDN serviceNetwork: 172.30.0.0/16 2. Check the net-attach-def created after the cluster setup 3. Actual results: The net-attach-def is created under default namespace and hardly be used. Means the additionalNetwork is kind of useless. Expected results: Should be able to modify the namespace value or put it under multusNamespace which introduced in https://github.com/intel/multus-cni/pull/254 Additional info:
Dan, Can you take a look at this?
Dan, I've submit fix PR for that into upstream: https://github.com/intel/multus-cni/pull/271
Casay, Can I take it? If you don't mind, I assign it to me.
Casey and Dan, Let me clarify the above PR. From multus side, we have issue around clusterNetwork, https://github.com/intel/multus-cni/issues/261 Multus will choose different namesppace for clusterNetwork (it should be multusNamespace, but actually it reads from default). Above PR is to fix this issue.
(In reply to Tomofumi Hayashi from comment #4) > Casey and Dan, > > Let me clarify the above PR. > From multus side, we have issue around clusterNetwork, > https://github.com/intel/multus-cni/issues/261 > Multus will choose different namesppace for clusterNetwork (it should be > multusNamespace, but actually it reads from default). > Above PR is to fix this issue. I think there are two folders of this problem: 1) Even multus supports 'systemNamespaces' and 'multusNamespace', it's not configurable via operator. 2) In operator, the namespace in net-attach-def custom resource template is hardcoded to 'default' namespace.
@Tomofumi I see the multus-cni plugin has merged. Do we need to do anything to bring that code in to OpenShift 4.1?
https://github.com/openshift/api/pull/294 https://github.com/openshift/cluster-network-operator/pull/152
Tested on 4.1.0-0.nightly-2019-05-08-065958 The additional network can be created in the specified namespace. spec: additionalNetworks: - name: sriov-conf namespace: openshift-sriov rawCNIConfig: '{ "type": "sriov", "name": "sriov-network", "ipam": { "type": "host-local", "subnet": "10.11.11.0/24", "routes": [{ "dst": "0.0.0.0/0" }], "gateway": "10.11.11.1" } }' type: Raw clusterNetwork: - cidr: 10.128.0.0/14 hostPrefix: 23 defaultNetwork: openshiftSDNConfig: mode: NetworkPolicy type: OpenShiftSDN serviceNetwork: - 172.30.0.0/16
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