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:
I am seeing this on OpenShift 4.11.20 with OpenShift Virtualization 4.11.1.
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,
(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
Created attachment 1948243 [details] vm yaml ``` 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
Move the bug to virt for a look.
Set it to high as it blocks the VM to start.
Moving this to the networking component as it appears to be a better fit. Please feel free to change this back if it turns out I'm wrong.
The name should be in format "<namespace>/<name>". The VM that failed has it the other way around. Guohua, could you try again, but this time, set `networkName: default/br1`
(In reply to Petr Horáček from comment #8) > The name should be in format "<namespace>/<name>". The VM that failed has it > the other way around. Guohua, could you try again, but this time, set > `networkName: default/br1` yes, it works. Move the bug to UX for further fix.
Should the non-priv user able to use the global network attachment definition as well? The current fix only apply to admin user.
(In reply to Guohua Ouyang from comment #10) > Should the non-priv user able to use the global network attachment > definition as well? > The current fix only apply to admin user. Its working the same for admin and regular user, it will try to fetch all global ns , if user has privileges it will present if not it wont. @gouyang
(In reply to Matan Schatzman from comment #11) > (In reply to Guohua Ouyang from comment #10) > > Should the non-priv user able to use the global network attachment > > definition as well? > > The current fix only apply to admin user. > > Its working the same for admin and regular user, it will try to fetch all > global ns , if user has privileges it will present if not it wont. > @gouyang The regular user cannot list the nad resource in default ns even with view permission: $ oc adm policy add-role-to-user view -n default test clusterrole.rbac.authorization.k8s.io/view added: "test" $ oc login -u test -p test $ oc get net-attach-def -n default Error from server (Forbidden): network-attachment-definitions.k8s.cni.cncf.io is forbidden: User "test" cannot list resource "network-attachment-definitions" in API group "k8s.cni.cncf.io" in the namespace "default"
Move the bug to verified as the UI display the network correctly and the VM can be scheduled.
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 (Moderate: OpenShift Virtualization 4.13.0 Images security, bug fix, and enhancement update), 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/RHSA-2023:3205