Bug 2224990

Summary: User is able to select incompatible network binding
Product: Container Native Virtualization (CNV) Reporter: Petr Horáček <phoracek>
Component: User ExperienceAssignee: Tal Nisan <tnisan>
Status: CLOSED ERRATA QA Contact: Guohua Ouyang <gouyang>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.13.0CC: gouyang, ycui
Target Milestone: ---   
Target Release: 4.14.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-11-08 14:06:02 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:
Bug Depends On:    
Bug Blocks: 2214457    

Description Petr Horáček 2023-07-24 08:02:29 UTC
Description of problem:
When adding a new network interface to a VM, user is allowed to select an incorrect binding. e.g. They can request an additional bridge network attachment definition and select SR-IOV binding for that. This is bad because of it would always end up with a failure and because it is confusing to the user. This can be easily avoided by setting the binding method automatically.   

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

How reproducible:
Always

Steps to Reproduce:
1. Create a new VM from a Template
2. Customize Virtual Machine
3. Network Interfaces
4. Add network interface
5. Select a "Network" (NetworkAttachmentDefinition)

Actual results:
The "Type" dropdown offers both SR-IOV and Bridge

Expected results:
The "Type" is not shown and the UI select the "Type" based on the NetworkAttachmentDefinition's own type.

Additional info:

Reading the NetworkAttachmentDefinition type:
The type in the NetworkAttachmentDefinition can be available in one of two schemas.
a)
  apiVersion: "k8s.cni.cncf.io/v1"
  kind: NetworkAttachmentDefinition
  metadata:
    name: <bridge-network> 
    annotations:
      k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/<bridge-interface> 
  spec:
    config: '{
      "cniVersion": "0.3.1",
      "name": "<bridge-network>", 
      "type": "cnv-bridge", # <---------
      "bridge": "<bridge-interface>", 
      "macspoofchk": true, 
      "vlan": 1 
    }'
b)
  apiVersion: "k8s.cni.cncf.io/v1"
  kind: NetworkAttachmentDefinition
  metadata:
    name: <bridge-network>
    annotations:
      k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/<bridge-interface>
  spec:
    config: '{
        "cniVersion": "0.3.1",
        "name": "<bridge-network>",
        "plugins": [
          {
            "type": "cnv-bridge" # <------ first item in the "plugins" list
          },
          {
            "type": "tuning"
          }
        ]
      }'


Mapping the NetworkAttachmentDefinition type to binding type:
bridge -> Bridge
cnv-bridge -> Bridge
sriov -> SR-IOV

Fallback:
In case we fail to detect the input, we should fall back to showing the dropdown. This can happen when:
a) RBAC does not allow us to read the NetworkAttachmentDefinition's contents
b) The NetworkAttachmentDefinition has an incorrect format
c) The NetworkAttachmentDefinition uses a type that is not supported by the UI (but still may be supported by the backend).

Comment 1 Guohua Ouyang 2023-08-02 04:39:57 UTC
verified on kubevirt-console-plugin-rhel9:v4.14.0-2373

Comment 3 errata-xmlrpc 2023-11-08 14:06:02 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 (Important: OpenShift Virtualization 4.14.0 Images security and bug fix 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:6817