Bug 2218147

Summary: [Hot-plug] Hot-plug doesn't fail when no NetworkAttachmentDefinition exists
Product: Container Native Virtualization (CNV) Reporter: Yossi Segev <ysegev>
Component: NetworkingAssignee: Petr Horáček <phoracek>
Status: CLOSED NOTABUG QA Contact: Nir Rozen <nrozen>
Severity: low Docs Contact:
Priority: medium    
Version: 4.14.0CC: alkaplan
Target Milestone: ---   
Target Release: 4.15.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-08-17 07:40:14 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 Yossi Segev 2023-06-28 10:42:43 UTC 
Description of problem:
One of the conditions of hot-plugging an interface is the existence of a backing NetworkAttachmentDefinition, but this action succeeds even if this resource doesn't exist.

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


How reproducible:
Always


Steps to Reproduce:
1. Create and run a basic VM (no secondary NICs).
$ oc create ns yoss-ns
namespace/yoss-ns created
$ oc project yoss-ns
Now using project "yoss-ns" on server "https://api.net-ys-414o.rhos-psi.cnv-qe.rhood.us:6443".
$ oc apply -f vm-fedora.yaml 
virtualmachine.kubevirt.io/vm-fedora created
$ virtctl start vm-fedora
VM vm-fedora was scheduled to start

2. Create a bridge interface over one of the nodes secondary NICs using a NodeNetworkConfigurationPolicy.
$ oc apply -f nncp-linux-bridge.yaml 
oc get nncp -w
nodenetworkconfigurationpolicy.nmstate.io/hotplug-linux-bridge created
ysegev@ysegev-fedora (hotplug) $ oc get nncp -w
NAME                   STATUS   REASON
hotplug-linux-bridge            
hotplug-linux-bridge   Progressing   ConfigurationProgressing
hotplug-linux-bridge   Progressing   ConfigurationProgressing
...
hotplug-linux-bridge   Available     SuccessfullyConfigured

3. Run the command to add the new interface to the VM:
virtctl addinterface <vm-name> --network-attachment-definition-name <net-attach-def-name> --name <interface-name>
$ virtctl addinterface vm-fedora --network-attachment-definition-name hp-br-nad --name hp2


Actual results:
<BUG> The action succeeds, with no failure.
The new interface appears in the VMI spec:
$ oc get vmi vm-fedora -o yaml
...
      interfaces:
      - masquerade: {}
        name: default
      - bridge: {}
        name: hp2
...
  networks:
  - name: default
    pod: {}
  - multus:
      networkName: hp-br-nad
    name: hp2


Expected results:
The action should fail with an error message.


Additional info:
Comment 3 Petr Horáček 2023-07-24 09:45:11 UTC 
Deferring to 4.15 due to severity
Comment 4 Alona Kaplan 2023-08-14 09:55:50 UTC 
Yossi, I believe that if the NAD will be eventually added the hotplug will succeed (maybe migration is needed after adding the NAD?).
Can you please also check if the behavior is consistent with starting a VM with a missing NAD?
Comment 5 Yossi Segev 2023-08-14 11:02:51 UTC 
(In reply to Alona Kaplan from comment #4)
> Yossi, I believe that if the NAD will be eventually added the hotplug will
> succeed (maybe migration is needed after adding the NAD?).
> Can you please also check if the behavior is consistent with starting a VM
> with a missing NAD?

I performed 2 extra checks per what we discussed in our meeting (and requested above by Alona):
1.
Starting a VMI with secondary network and interface - with a missing NAD:
a. The VMI is stuck on Pending status:
$ oc get vmi
NAME          AGE     PHASE     IP    NODENAME   READY
vm-fedora-2   3m43s   Pending                    False

b. An explicit failure is reported in the VMI status:
{
  "conditions": [
    {
      "lastProbeTime": "2023-08-14T10:34:57Z",
      "lastTransitionTime": "2023-08-14T10:34:57Z",
      "message": "virt-launcher pod has not yet been scheduled",
      "reason": "PodNotExists",
      "status": "False",
      "type": "Ready"
    },
    {
      "lastProbeTime": null,
      "lastTransitionTime": "2023-08-14T10:34:57Z",
      "message": "failed to render launch manifest: Failed to locate network attachment definition yoss-ns/hp-br-nad",
      "reason": "FailedCreate",
      "status": "False",
      "type": "Synchronized"
    }
  ],
  "currentCPUTopology": {
    "cores": 1,
    "sockets": 1,
    "threads": 1
  },
  "guestOSInfo": {},
  "phase": "Pending",
  "phaseTransitionTimestamps": [
    {
      "phase": "Pending",
      "phaseTransitionTimestamp": "2023-08-14T10:34:56Z"
    }
  ],
  "runtimeUser": 107,
  "virtualMachineRevisionName": "revision-start-vm-0ae504d7-1770-410a-b50d-7657397818d9-2"
}

No virt-launcher is created yet, so no logs.
No failure event reported (`oc get events` doesn't produce any output failure even).


2.
Hot-plugging an interface without a NAD (the original scenario of this BZ), and then adding a NAD:
This scenario is completed successfully, i.e. after adding the NAD (and migrating) - the hot-plugged interface appears in the guest VM.
No failure events found.
Comment 6 Yossi Segev 2023-08-17 07:40:14 UTC 
As discussed with the devs - no alert or failure upon hot-plugging an interface with no backing NAD does conform to the Kubernetes way, therefore we can consider this flow as valid, and can close this bug.