Bug 2218147 - [Hot-plug] Hot-plug doesn't fail when no NetworkAttachmentDefinition exists
Summary: [Hot-plug] Hot-plug doesn't fail when no NetworkAttachmentDefinition exists
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Networking
Version: 4.14.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: 4.15.0
Assignee: Petr Horáček
QA Contact: Nir Rozen
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-06-28 10:42 UTC by Yossi Segev
Modified: 2023-08-17 07:40 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-08-17 07:40:14 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker CNV-30367 0 None None None 2023-06-28 10:44:27 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.