+++ This bug was initially created as a clone of Bug #2158424 +++

Description of problem:
When the user wants to add a secondary interface to a VM using the UI, he/she must specify which is the name of the network attachment definition to use, as per [0].

The current implementation only shows NADs (network attachment definitions) from the namespace of the VMI; however, there is a feature in multus (which is being used in openshift) where some namespaces are globally available to the user (i.e. the user can refer to NADs in these global namespaces, even if the VM is going to be created in a different namespace) - [1].

To keep this consistent, the UI should present the NADs present in these global namespaces as well - the list is configured by the cluster networks operator, and can be seen in [2].

When

[0] - https://access.redhat.com/documentation/en-us/openshift_container_platform/4.11/html/virtualization/virtual-machines#virt-networking-wizard-fields-web_virt-create-vms

[1] - https://github.com/k8snetworkplumbingwg/multus-cni/blob/master/docs/how-to-use.md # search for `--global-namespaces`

[2] - https://github.com/openshift/cluster-network-operator/blob/6abbcaf40079f0ac39182d6fbc960403a2698475/bindata/network/multus/multus.yaml#L163

Version-Release number of selected component (if applicable):

How reproducible:
Always.

Steps to Reproduce:
1. Provision the following net-attach-def (notice it is being created in the `default` namespace).
```
apiVersion: v1
items:

• apiVersion: k8s.cni.cncf.io/v1
  kind: NetworkAttachmentDefinition
  metadata:
  annotations:
  description: VLAN 104 (10.11.176.0/24)
  k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/br-cnv
  name: vlan104
  namespace: default
  spec:
  config: '{"name":"vlan104","type":"cnv-bridge","cniVersion":"0.3.1","bridge":"br-cnv","vlan":104,"macspoofchk":false,"ipam":{}}'
  ```

2. Try to consume this NAD when creating a VM using the wizard
3.

Actual results:
The NAD created in this global namespace will not be listed in the UI.

Expected results:
The NAD created in this global namespace should be listed in the UI.

Additional info:

— Additional comment from Ian Pilcher on 2023-01-05 22:10:05 CST —

I am seeing this on OpenShift 4.11.20 with OpenShift Virtualization 4.11.1.

— Additional comment from Guohua Ouyang on 2023-01-11 09:43:02 CST —

Hi,
I'm trying to understand the bug, but I cannot get much information about global namespace by searching it in internet. How can I create a global namespace in openshift or how to verify a namespace is the global namespace? Do you think 'default' is the global namespace?

Thanks,

— Additional comment from Miguel Duarte Barroso on 2023-01-12 00:10:41 CST —

(In reply to Guohua Ouyang from comment #2)
> Hi,
> I'm trying to understand the bug, but I cannot get much information about
> global namespace by searching it in internet. How can I create a global
> namespace in openshift or how to verify a namespace is the global namespace?

AFAIU, you cannot created global namespaces.

You can use the ones that are shipped in openshift - those are listed in [0]; this list is hard-coded in the network operator.

I would create a net-attach-def in the `default` namespace, create a pod in a separate namespace, and ensure the NADs in the
drop down list also show the one you've created on the default NS.

> Do you think 'default' is the global namespace?

Yes, that namespace is global - i.e. it is defined in the list shown in [0].
>
> Thanks,

[0] - https://github.com/openshift/cluster-network-operator/blob/6abbcaf40079f0ac39182d6fbc960403a2698475/bindata/network/multus/multus.yaml#L163

— Additional comment from Guohua Ouyang on 2023-03-06 10:37:58 CST —

```
message: >-
failed to render launch manifest: Failed to locate network attachment
definition br1/default
```

It looks the backend does not support this scenario.
Reproduces steps:
1. add a nad to namespace "default"
2. create vm in another namespace "test" and select the network from ns "default".
3. the VM is not schedulable

— Additional comment from Guohua Ouyang on 2023-03-06 10:39:01 CST —

Move the bug to virt for a look.