STP for Live Update NetworkAttachmentDefinition Reference (VEP 140)#39
Open
yossisegev wants to merge 4 commits intoRedHatQE:mainfrom
Open
STP for Live Update NetworkAttachmentDefinition Reference (VEP 140)#39yossisegev wants to merge 4 commits intoRedHatQE:mainfrom
yossisegev wants to merge 4 commits intoRedHatQE:mainfrom
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughAdds a new Software Test Plan document for LiveUpdateNADRef (hotpluggable NAD reference) covering metadata, conventions, feature overview, requirements, test strategy, detailed test cases (TC-0..TC-11), environment/tooling, risks/limitations, traceability, and sign-off criteria. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Report bugs in Issues Welcome! 🎉This pull request will be automatically processed with the following features: 🔄 Automatic Actions
📋 Available CommandsPR Status Management
Review & Approval
Testing & Validation
Cherry-pick Operations
Label Management
✅ Merge RequirementsThis PR will be automatically approved when the following conditions are met:
📊 Review ProcessApprovers and ReviewersApprovers:
Reviewers:
Available Labels
💡 Tips
For more information, please refer to the project documentation or contact the maintainers. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@stps/sig-network/hotpluggable-nad-ref-stp.md`:
- Line 32: Fix the typos across the document by replacing the incorrect tokens
with the corrected spellings: change "NAd reference" to "NAD reference",
"dependecny" -> "dependency", "implmenetation" -> "implementation", "backgrond"
-> "background", "letncy cannot be measured,for example" -> "latency cannot be
measured, for example", "evetually" -> "eventually", "is mot affected" -> "is
not affected", "dependancy" -> "dependency", "migartion" -> "migration",
"refelcted" -> "reflected", "environemnt" -> "environment", and "migratin" ->
"migration"; ensure you update each occurrence of the quoted phrases (e.g., the
header/text containing "NAd reference", the paragraphs with
"dependecny"/"implmenetation", the sentence with "letncy...", etc.) so the
document reads correctly and consistently.
- Around line 156-162: Update the traceability table to add a Requirement row
for the "P1 feature-gate disabled behavior" mapping the in-scope item "Verify
behavior when LiveUpdateNADRef feature-gate is disabled (attempting to change
NAD reference produces failure/error)" to a Test Scenario that attempts a
networkName update with the feature-gate off and asserts failure/error, and add
another Requirement row for "MAC preservation" mapping the in-scope item
"Verifying that guest interface identity (e.g. MAC) is preserved where
applicable" to a Test Scenario that changes NAD reference and verifies the guest
MAC is unchanged; also update the existing VEP-140 (NFR) regression row to
explicitly mention "interface hot-plug regression" in the Requirement
Summary/Test Scenario to reflect the specific regression concern named elsewhere
in the document.
frenzyfriday
left a comment
frenzyfriday
left a comment
There was a problem hiding this comment.
Thanks for the STP! Lgtm in general, just a few questions/comments
azhivovk
suggested changes
Feb 26, 2026
Anatw
reviewed
Mar 1, 2026
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
stps/sig-network/hotpluggable-nad-ref-stp.md (1)
91-92:⚠️ Potential issue | 🟡 MinorFix remaining spelling errors in strategy table entries.
There are still typos in these rows (
exisiting,reqiurement,byt,hance). Please correct them to avoid ambiguity in a formal STP.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@stps/sig-network/hotpluggable-nad-ref-stp.md` around lines 91 - 92, Fix typos in the strategy table entries: in the row that begins with "Dependencies" replace "exisiting" with "existing" and "reqiurement" with "requirement" (the cell containing "KubeVirt virt-controller; Multus (just exisiting functionality, no new reqiurement); optional DNC"), and in the "Cross Integrations" row replace "byt" with "by" and "hance" with "hence" (the cell containing "Bridge binding in VMs is tested byt network SIG, hance changes in bridge binding are also under the network sig testing domain."); update only those words so the rest of the phrasing remains unchanged.
🧹 Nitpick comments (2)
stps/sig-network/hotpluggable-nad-ref-stp.md (2)
155-161: Optionally reduce Requirement ID repetition in traceability rows.For rows under the same epic, consider keeping the first Requirement ID populated and leaving subsequent Requirement ID cells empty to reduce redundancy.
Based on learnings: In the openshift-virtualization-tests-design-docs repository, when documenting test scenarios in the "Test Scenarios & Traceability" table where multiple test scenarios fall under the same epic, it's acceptable and preferred to leave the Requirement ID cells empty for subsequent rows after the first row which contains the epic ID.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@stps/sig-network/hotpluggable-nad-ref-stp.md` around lines 155 - 161, The table repeats the same Requirement ID "VEP-140" across multiple rows; update the "Test Scenarios & Traceability" table so only the first row for the epic contains "VEP-140" in the Requirement ID column and remove (empty) the Requirement ID cells for the subsequent rows that belong to the same epic (rows containing the summaries "Change NAD reference on running VM...", "Migration triggered and completes...", "RestartRequired not set...", "No regression in secondary network...", and "Guest interface identity preserved...") to reduce redundancy while keeping the Test Scenario(s), Tier, and Priority columns unchanged.
102-102: Consider using version-range wording for long-lived STP clarity.Instead of a single fixed version (
4.22), consider phrasing as4.22 onward(and optionally note backportability if applicable) to keep this plan accurate across releases.Based on learnings: In the openshift-virtualization-tests-design-docs repository, when documenting "OCP & OpenShift Virtualization Version(s)" in STP test environment tables, features may specify "v4.X onward" while also noting "Can be backported to all versions."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@stps/sig-network/hotpluggable-nad-ref-stp.md` at line 102, Update the version wording in the STP table entry for "OCP & OpenShift Virtualization Version(s)" where "4.22" is currently used for the LiveUpdateNADRef feature: replace the fixed "4.22" with a range-style phrase such as "4.22 onward" and optionally append a short parenthetical note like "(can be backported where applicable)" next to the LiveUpdateNADRef mention to indicate long-lived applicability and backportability.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@stps/sig-network/hotpluggable-nad-ref-stp.md`:
- Line 64: The P2 goal "Verify behavior when LiveUpdateNADRef feature-gate is
disabled (e.g. attempting to change NAD reference produces failure/error)" is
not present in the traceability table; either add a corresponding mapping row in
the traceability table that references this exact P2 goal and points to the
related test cases/requirements, or remove that P2 goal line entirely if it is
out of scope; update the traceability table entries that enumerate
goals-to-tests so the P2 feature-gate-disabled scenario is consistently
represented (or removed) throughout the document.
---
Duplicate comments:
In `@stps/sig-network/hotpluggable-nad-ref-stp.md`:
- Around line 91-92: Fix typos in the strategy table entries: in the row that
begins with "Dependencies" replace "exisiting" with "existing" and "reqiurement"
with "requirement" (the cell containing "KubeVirt virt-controller; Multus (just
exisiting functionality, no new reqiurement); optional DNC"), and in the "Cross
Integrations" row replace "byt" with "by" and "hance" with "hence" (the cell
containing "Bridge binding in VMs is tested byt network SIG, hance changes in
bridge binding are also under the network sig testing domain."); update only
those words so the rest of the phrasing remains unchanged.
---
Nitpick comments:
In `@stps/sig-network/hotpluggable-nad-ref-stp.md`:
- Around line 155-161: The table repeats the same Requirement ID "VEP-140"
across multiple rows; update the "Test Scenarios & Traceability" table so only
the first row for the epic contains "VEP-140" in the Requirement ID column and
remove (empty) the Requirement ID cells for the subsequent rows that belong to
the same epic (rows containing the summaries "Change NAD reference on running
VM...", "Migration triggered and completes...", "RestartRequired not set...",
"No regression in secondary network...", and "Guest interface identity
preserved...") to reduce redundancy while keeping the Test Scenario(s), Tier,
and Priority columns unchanged.
- Line 102: Update the version wording in the STP table entry for "OCP &
OpenShift Virtualization Version(s)" where "4.22" is currently used for the
LiveUpdateNADRef feature: replace the fixed "4.22" with a range-style phrase
such as "4.22 onward" and optionally append a short parenthetical note like
"(can be backported where applicable)" next to the LiveUpdateNADRef mention to
indicate long-lived applicability and backportability.
azhivovk
approved these changes
Mar 15, 2026
yossisegev
force-pushed
the
hot-nad-swap
branch
from
e18c106 to
694c2d9
Compare
openshift-virtualization-qe-bot-3
added
commented-yossisegev
and removed
needs-rebase
labels
ronensdeor
reviewed
Mar 16, 2026
yossisegev
force-pushed
the
hot-nad-swap
branch
from
694c2d9 to
e091404
Compare
openshift-virtualization-qe-bot-5
added
needs-rebase
and removed
commented-yossisegev
commented-ronensdeor
labels
azhivovk
approved these changes
Mar 18, 2026
Anatw
reviewed
Mar 19, 2026
Anatw
reviewed
Mar 19, 2026
EdDev
suggested changes
Mar 25, 2026
Collaborator
EdDev
left a comment
EdDev
left a comment
There was a problem hiding this comment.
I reviewed this STP until the out-of-scope section including.
There are enough items that need attention to stop there.
Based on the PM's review comment next to the out-of-scope section.
This batch has many fixes, so I prefer having it in a separate commit (although it is only fixes) for easier review.
3 tasks
EdDev
reviewed
Mar 26, 2026
Collaborator
EdDev
left a comment
EdDev
left a comment
There was a problem hiding this comment.
Following up on my previous review - there are still 5 items that need attention before approval.
|
|
||
| ### **Feature Overview** | ||
|
|
||
| This feature enables VM owners to change the NetworkAttachmentDefinition reference (`networkName`) of a secondary network on a **running** VM without rebooting. When the user updates `spec.networks[].multus.networkName` in the VM spec, the system triggers a Live Migration, so the VM’s new pod will now be plumbed to the new network (e.g., a different VLAN). Today, changing the NAD reference requires a VM restart. The enhancement uses the existing migration path: no reboot, and guest interface properties (e.g., MAC) stay the same.\ |
Collaborator
There was a problem hiding this comment.
This is an implementation detail and should not be mentioned. Users don't need to know how the feature is implemented internally. Please rephrase to focus on the user-facing behavior.
Suggested change:
Suggested change
| This feature enables VM owners to change the NetworkAttachmentDefinition reference (`networkName`) of a secondary network on a **running** VM without rebooting. When the user updates `spec.networks[].multus.networkName` in the VM spec, the system triggers a Live Migration, so the VM’s new pod will now be plumbed to the new network (e.g., a different VLAN). Today, changing the NAD reference requires a VM restart. The enhancement uses the existing migration path: no reboot, and guest interface properties (e.g., MAC) stay the same.\ | |
| This feature enables VM owners to change the NetworkAttachmentDefinition reference (`networkName`) of a secondary network on a **running** VM without rebooting. When the user updates `spec.networks[].multus.networkName` in the VM spec, the VM will be reconnected to the new network (e.g., a different VLAN) without requiring a restart.\ |
| | **Network** | Secondary networks | At least two NADs (e.g., different VLANs/bridges) for bridge binding; Multus configured. To reduce resource dependency, it might be worth considering referring to the same node bridge in the 2 NADs. | | ||
| | **Required Operators** | Standard | OpenShift Virtualization; Multus; NMState | | ||
| | **Platform** | Standard | Agnostic | | ||
| | **Special Configurations** | Feature gate | LiveUpdateNADRef enabled for positive tests | |
Collaborator
There was a problem hiding this comment.
The LiveUpdateNADRef feature gate is NOT exposed to users and should not be mentioned in the STP. Please remove this reference.
Suggested change:
Suggested change
| | **Special Configurations** | Feature gate | LiveUpdateNADRef enabled for positive tests | | |
| | **Special Configurations** | N/A | None required | |
|
|
||
| - [X] VEP/design is **approved and merged** upstream; feature available in target OCP/OpenShift Virtualization version. | ||
| - [ ] Test environment can be **set up and configured** (see Section II.3 - Test Environment). | ||
| - [ ] Feature gate **LiveUpdateNADRef** is configurable in the test environment, or set on day-0 |
Collaborator
There was a problem hiding this comment.
The LiveUpdateNADRef feature gate is NOT exposed to users and should not be mentioned in the STP. Please remove this entire line.
| | **Customer Use Cases** | [x] | As a VM owner, I should be able to re-assign VMs to a new VLAN ID without having to reboot my VMs. | | | ||
| | **Testability** | [x] | Core flow is testable (see III. Test Scenarios & Traceability). | | | ||
| | **Acceptance Criteria** | [x] | Change NAD reference on a VM and verify VM is connected to the new network and has connectivity (per VEP Functional Testing Approach). | | | ||
| | **Non-Functional Requirements (NFRs)** | [x] | No new NFRs called out. Documentation and E2E coverage required for Beta/GA. | | |
Collaborator
There was a problem hiding this comment.
Please use only product/downstream terms, not upstream ones like "Beta/GA".
Suggested change:
Suggested change
| | **Non-Functional Requirements (NFRs)** | [x] | No new NFRs called out. Documentation and E2E coverage required for Beta/GA. | | | |
| | **Non-Functional Requirements (NFRs)** | [x] | No new NFRs called out. Documentation and E2E coverage required. | | |
| | Requirement ID | Requirement Summary | Test Scenario(s) | Tier | Priority | | ||
| |:---------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-------|:---------| | ||
| | TC-0 | As a VM owner, I want to be able to connect an exisitng interface to a different network while preserving connectivity. | Change NAD reference on running VM (bridge) via migration; VM on new network and has connectivity | Tier 2 | P0 | | ||
| | TC-1 | As a VM owner where net newtork should be configured for existing secondary interface, I want to make sure that guest interface identity preserved during NAD reference change | Change networkName → verify MAC address and interface name remain unchanged after migration | Tier 2 | P2 | |
Collaborator
There was a problem hiding this comment.
Verifying MAC address preservation is too low level. No one changed the NIC identity when updating the VM spec, so it's not expected to change. Instead, check higher-level behavior that actually matters to users, like TCP connection preservation or continuous connectivity. If you need to verify identity preservation in a general manner, use other means.
Consider replacing TC-1 with a test that verifies continuous connectivity or TCP connection preservation during NAD reference change, rather than checking MAC addresses.
| | Regression Testing | Verifies that new changes do not break existing functionality | Y | Connectivity post NAD-change; user-initiated migration post NAD-change. | | ||
| | Upgrade Testing | Validates upgrade paths from previous versions, data migration, and configuration preservation | N | Expected to function on upgraded clusters after feature-gate enablement | | ||
| | Backward Compatibility Testing | Ensures feature maintains compatibility with previous API versions and configurations | Y | Verify the existing interface hot-plug feature is not affected | | ||
| | Dependencies | Dependent on deliverables from other components/products? | Y | KubeVirt virt-controller; Multus (just exisiting functionality, no new requirement); optional DNC | |
Collaborator
There was a problem hiding this comment.
Typo: "exisiting" should be "existing"
Suggested change:
Suggested change
| | Dependencies | Dependent on deliverables from other components/products? | Y | KubeVirt virt-controller; Multus (just exisiting functionality, no new requirement); optional DNC | | |
| | Dependencies | Dependent on deliverables from other components/products? | Y | KubeVirt virt-controller; Multus (just existing functionality, no new requirement); optional DNC | |
|
|
||
| | Requirement ID | Requirement Summary | Test Scenario(s) | Tier | Priority | | ||
| |:---------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-------|:---------| | ||
| | TC-0 | As a VM owner, I want to be able to connect an exisitng interface to a different network while preserving connectivity. | Change NAD reference on running VM (bridge) via migration; VM on new network and has connectivity | Tier 2 | P0 | |
Collaborator
There was a problem hiding this comment.
Two issues here:
- Typo: "exisitng" should be "existing"
- "via migration" is an implementation detail and should be removed
Suggested change:
Suggested change
| | TC-0 | As a VM owner, I want to be able to connect an exisitng interface to a different network while preserving connectivity. | Change NAD reference on running VM (bridge) via migration; VM on new network and has connectivity | Tier 2 | P0 | | |
| | TC-0 | As a VM owner, I want to be able to connect an existing interface to a different network while preserving connectivity. | Change NAD reference on running VM (bridge); VM on new network and has connectivity | Tier 2 | P0 | |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
STP Metadata
VEP issue: https://github.com/kubevirt/enhancements/blob/main/veps/sig-network/hotpluggable-nad-ref.md
What this PR does
STP for covering updating network (NAD) reference on live VMs.
Special notes for your reviewer
Summary by CodeRabbit