Bug 1751070

Summary: NetworkAttachmentDefinition always be created in 'default' namespaces
Product: OpenShift Container Platform Reporter: zhaozhanqi <zzhao>
Component: NetworkingAssignee: Douglas Smith <dosmith>
Networking sub component: openshift-sdn QA Contact: zhaozhanqi <zzhao>
Status: CLOSED ERRATA Docs Contact:
Severity: medium    
Priority: medium CC: dosmith
Version: 4.2.0   
Target Milestone: ---   
Target Release: 4.2.0   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-10-16 06:40:54 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:
Embargoed:

Description zhaozhanqi 2019-09-11 06:40:34 UTC
Description of problem:
when edit network.operator by ` oc edit networks.operator.openshift.io` and add the following:

spec:
  additionalNetworks:
  - name: test-macvlan-case3
    namespace: openshift-multus
    simpleMacvlanConfig:
      ipamConfig:
        staticIPAMConfig:
          addresses:
          - address: 10.128.2.100/23
            gateway: 10.128.2.1
          dns:
            domain: us-west-2.compute.internal
            nameservers:
            - 172.30.0.10
            search:
            - us-west-2.compute.internal
          routes:
          - destination: 0.0.0.0/0
            gateway: 10.128.2.1
        type: static
      master: ens5
      mode: bridge
    type: SimpleMacvlan

in above the 'namespace: openshift-multus' is specified. but I found the NAD is created in 'default' namespaces.

Version-Release number of selected component (if applicable):
4.2.0-0.nightly-2019-09-10-181551

How reproducible:
always

Steps to Reproduce:
1. oc edit networks.operator.openshift.io

  -------
    additionalNetworks:
  - name: test-macvlan-case3
    namespace: openshift-sdn
    simpleMacvlanConfig:
      ipamConfig:
        staticIPAMConfig:
          addresses:
          - address: 10.128.2.100/23
            gateway: 10.128.2.1
          dns:
            domain: us-west-2.compute.internal
            nameservers:
            - 172.30.0.10
            search:
            - us-west-2.compute.internal
          routes:
          - destination: 0.0.0.0/0
            gateway: 10.128.2.1
        type: static
      master: ens5
      mode: bridge
    type: SimpleMacvlan
  ------------------------------
2.  After a while. check the network-attachment-definitions
 # oc get network-attachment-definitions.k8s.cni.cncf.io --all-namespaces
NAMESPACE   NAME                 AGE
default     test-macvlan-case3   24m
3. Check the logs in CNO

 oc logs network-operator-5bb75f89bb-pzrfv | grep test-macvlan-case3
2019/09/11 06:01:10 reconciling (k8s.cni.cncf.io/v1, Kind=NetworkAttachmentDefinition) default/test-macvlan-case3
2019/09/11 06:01:11 does not exist, creating (k8s.cni.cncf.io/v1, Kind=NetworkAttachmentDefinition) default/test-macvlan-case3
2019/09/11 06:01:11 successfully created (k8s.cni.cncf.io/v1, Kind=NetworkAttachmentDefinition) default/test-macvlan-case3
2019/09/11 06:03:09 reconciling (k8s.cni.cncf.io/v1, Kind=NetworkAttachmentDefinition) default/test-macvlan-case3
2019/09/11 06:08:21 reconciling (k8s.cni.cncf.io/v1, Kind=NetworkAttachmentDefinition) default/test-macvlan-case3
2019/09/11 06:13:34 reconciling (k8s.cni.cncf.io/v1, Kind=NetworkAttachmentDefinition) default/test-macvlan-case3


Actual results:

step 2:

network-attachment-definitions.k8s.cni.cncf.io was created in 'default' namespaces

Expected results:

network-attachment-definitions.k8s.cni.cncf.io should be created in specified namespaces

Additional info:

Comment 1 Douglas Smith 2019-09-11 18:58:11 UTC
Looks like there was a minor oversight in the SimpleMacvlan rendering method, it wasn't sending the "AdditionalNetworkNamespace" to the data as used in the template. 

PR to fix available @ https://github.com/openshift/cluster-network-operator/pull/314

Comment 3 zhaozhanqi 2019-09-16 05:53:14 UTC
verified this bug on 4.2.0-0.nightly-2019-09-15-052022

Comment 4 errata-xmlrpc 2019-10-16 06:40:54 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:2922