Skip to content

[Virt] Multi arch STP #19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
akri3i wants to merge 4 commits into
base: main
Choose a base branch
from
Open

[Virt] Multi arch STP #19

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
06f0a9c
[Virt] Multi arch STP
akri3i Jan 9, 2026
86fc1c8
[pre-commit.ci] auto fixes from pre-commit.com hooks
pre-commit-ci[bot] Jan 9, 2026
e09b792
Apply suggestions from code review
akri3i Jan 16, 2026
571aaf5
Merge branch 'main' into multi-arch
akri3i Feb 10, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
187 changes: 187 additions & 0 deletions stps/sig-virt/multiarch_support.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,187 @@
# Openshift-virtualization-tests Test plan

## VM creation and Live Migration on a multi arch cluster - Quality Engineering Plan**

### **Metadata & Tracking**

| Field | Details |
| :--------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Enhancement(s)** | [dic-on-heterogeneous-cluster](https://github.com/kubevirt/enhancements/blob/main/veps/sig-storage/dic-on-heterogeneous-cluster/dic-on-heterogeneous-cluster.md) |
| **Feature in Jira** | [VIRTSTRAT-494](https://issues.redhat.com/browse/VIRTSTRAT-494) |
| **Jira Tracking** | [CNV-26818](https://issues.redhat.com/browse/CNV-26818) |
| **QE Owner(s)** | Akriti Gupta |
| **Owning SIG** | sig-iuo |
| **Participating SIGs** | sig-infra, sig-storage, sig-virt |
| **Current Status** | Draft |

**Document Conventions (if applicable):** [Define acronyms or terms specific to this document]
- VM : Virtual Machine
Comment on lines +17 to +18
Copy link

@coderabbitai coderabbitai bot Jan 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Replace the document-conventions placeholder.
Line 17 still contains the template instruction. Either remove it or replace with real acronyms/terms for this plan.

🤖 Prompt for AI Agents 
In `@stps/sig-virt/multiarch_support.md` around lines 17 - 18, Remove the leftover
template line under the "Document Conventions" heading and either delete the
placeholder text or replace it with actual acronyms/terms used in this document
(for example keep "VM : Virtual Machine" and add any other relevant definitions
like "ABI", "OCI", "KVM" etc.); ensure the "Document Conventions" section only
contains concrete terminology entries and not template instructions so readers
see real conventions rather than a placeholder.

---


### **I. Motivation and Requirements Review (QE Review Guidelines)**

This section documents the mandatory QE review process. The goal is to understand the feature's value,
technology, and testability before formal test planning.

#### **1. Requirement & User Story Review Checklist**

| Check | Done | Details/Notes | Comments |
| :------------------------------------- | :--- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------- |
| **Review Requirements** | [x] | Reviewed the relevant requirements. | |
| **Understand Value** | [x] | Confirmed clear user stories and understood. <br/>Ensures workload uptime and hardware flexibility by enabling seamless VM creation and architecture-safe live migration across x86 and ARM nodes within a single managed cluster.<br/> | |
| **Customer Use Cases** | [x] | Ensured requirements contain relevant **customer use cases**. | |
| **Testability** | [x] | Confirmed requirements are **testable and unambiguous**. | |
| **Acceptance Criteria** | [x] | Ensured acceptance criteria are **defined clearly** (clear user stories; D/S requirements clearly defined in Jira). | |
| **Non-Functional Requirements (NFRs)** | [x] | Confirmed coverage for NFRs, including Performance, Security, Usability, Downtime, Connectivity, Monitoring (alerts/metrics), Scalability, Portability (e.g., cloud support), and Docs. | |


#### **2. Technology and Design Review**

| Check | Done | Details/Notes | Comments |
| :------------------------------- | :--- | :------------------------------------------------------------------------------------------------------------------------------------------------------ | :------- |
| **Developer Handoff/QE Kickoff** | [x] | A meeting where Dev/Arch walked QE through the design, architecture, and implementation details. **Critical for identifying untestable aspects early.** | |
| **Technology Challenges** | [x] | Identified potential testing challenges related to the underlying technology. | |
| **Test Environment Needs** | [x] | Determined necessary **test environment setups and tools**. | |
| **API Extensions** | [x] | Reviewed new or modified APIs and their impact on testing. | |
| **Topology Considerations** | [x] | Evaluated multi-cluster, network topology, and architectural impacts. | |


### **II. Software Test Plan (STP)**

This STP serves as the **overall roadmap for testing**, detailing the scope, approach, resources, and schedule.

#### **1. Scope of Testing**

This test plan checks if VMs schedules and live migrates correctly on a mixed architecture cluster
Copy link

@coderabbitai coderabbitai bot Jan 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Grammar: subject–verb agreement.
“VMs schedules” → “VMs schedule.”

🤖 Prompt for AI Agents 
In `@stps/sig-virt/multiarch_support.md` at line 56, The sentence "This test plan
checks if VMs schedules and live migrates correctly on a mixed architecture
cluster" has a subject–verb agreement error; update the phrase to "VMs schedule
and live migrate correctly" in multiarch_support.md (replace the existing
sentence) so the plural subject "VMs" pairs with plural verbs "schedule" and
"live migrate".


**In Scope:**
- Create VMs for both AMD64 and ARM64 arch types and confirm the cluster automatically schedules them on respective architecture node.
- Test VM creation using both golden image DataSources and custom Qcow2 images and ensure they always land on the right nodes.
Comment on lines +59 to +60
Copy link

@coderabbitai coderabbitai bot Jan 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion | 🟠 Major

Standardize architecture naming to lowercase throughout the document.

The document inconsistently uses "AMD64/ARM64" (uppercase) and "amd64/arm64" (lowercase). Per vsibirsk's feedback, KubeVirt uses lowercase. Standardize to amd64 and arm64 throughout for consistency.

Affected lines include 58-59, 72, 76, 148, and 168-170.

Based on learnings, vsibirsk indicated arch names should match KV convention: 'amd64' and 'arm64'.

♻️ Proposed fix for naming consistency 
-- Create VMs for both AMD64 and ARM64 arch types and confirm the cluster automatically schedules them on respective architecture node.
+- Create VMs for both amd64 and arm64 arch types and confirm the cluster automatically schedules them on respective architecture node.
-- Test VM creation using both golden image DataSources and custom Qcow2 images and ensure they always land on the right nodes.
+- Test VM creation using both golden image DataSources and custom Qcow2 images for both amd64 and arm64 architectures and ensure they always land on the right nodes.

Apply similar changes to lines 148, 168-170 to use lowercase architecture names consistently.

Also applies to: 72-72, 76-76, 148-148, 168-170

🤖 Prompt for AI Agents 
In `@stps/sig-virt/multiarch_support.md` around lines 58 - 59, Replace all
occurrences of the uppercase architecture names "AMD64" and "ARM64" with the
lowercase forms "amd64" and "arm64" throughout the document (notably the phrases
in the diff lines that mention creating VMs and tests and the other referenced
occurrences around lines 72, 76, 148, and 168-170), ensuring every instance
matches KubeVirt's convention; search for the exact tokens "AMD64" and "ARM64"
and perform a global, case-sensitive replace to "amd64" and "arm64" respectively
so naming is consistent across the file.

- Verify that VMs can Live Migrate between nodes of the same type (`amd64` to `amd64` and `arm64` to `arm64`) without issues.

**Out of Scope (Testing Scope Exclusions)**
**Note:** Replace example rows with your actual out-of-scope items.

| Out-of-Scope Item | Rationale | PM/ Lead Agreement |
| :----------------------------- | :------------------------------------------------------------------------ | :----------------- |
| Testing with container disk VM | There's no defaulting of the architecture based on the containerdisk arch | [ ] Name/Date |

Comment on lines +58 to +69
Copy link

@coderabbitai coderabbitai bot Jan 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Fix spelling error and complete the Out of Scope section.

Line 58 contains a spelling error ("thier" → "their"), and the Out of Scope section still has placeholder instruction text (line 63) that should be removed. The table needs to be populated with actual out-of-scope items relevant to this feature.

✏️ Proposed spelling fix 
-- Create VMs for both AMD and ARM and confirm the cluster automatically places them on thier respective architecture node.
+- Create VMs for both AMD and ARM and confirm the cluster automatically places them on their respective architecture node.
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
**In Scope:**
- Create VMs for both AMD and ARM and confirm the cluster automatically places them on thier respective architecture node.
- Test VM creation using both DataSources and Qcow2 images and ensure they always land on the right nodes.
- Verify that VMs can Live Migrate between nodes of the same type (x86 to x86 and ARM to ARM) without stopping.
**Out of Scope (Testing Scope Exclusions)**
**Note:** Replace example rows with your actual out-of-scope items.
| Out-of-Scope Item | Rationale | PM/ Lead Agreement |
| :----------------------------- | :------------------------------------------------------------------------ | :----------------- |
| Testing with container disk VM | There's no defaulting of the architecture based on the containerdisk arch | [ ] Name/Date |
**In Scope:**
- Create VMs for both AMD and ARM and confirm the cluster automatically places them on their respective architecture node.
- Test VM creation using both DataSources and Qcow2 images and ensure they always land on the right nodes.
- Verify that VMs can Live Migrate between nodes of the same type (x86 to x86 and ARM to ARM) without stopping.
**Out of Scope (Testing Scope Exclusions)**
**Note:** Replace example rows with your actual out-of-scope items.
| Out-of-Scope Item | Rationale | PM/ Lead Agreement |
| :----------------------------- | :------------------------------------------------------------------------ | :----------------- |
| Testing with container disk VM | There's no defaulting of the architecture based on the containerdisk arch | [ ] Name/Date |
🧰 Tools
🪛 LanguageTool

[grammar] ~58-~58: Ensure spelling is correct
Context: ...he cluster automatically places them on thier respective architecture node. - Test VM...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

🤖 Prompt for AI Agents 
In @stps/sig-virt/multiarch_support.md around lines 57 - 68, Fix the typo
"thier" → "their" in the "In Scope" bullet ("Create VMs for both AMD and ARM and
confirm the cluster automatically places them on their respective architecture
node.") and remove the placeholder note under the "Out of Scope (Testing Scope
Exclusions)" header; then replace the example placeholder table row(s) with real
out-of-scope items relevant to multi-arch VM testing (e.g., "Testing with
container disk VM" with rationale and PM/Lead agreement), ensuring the table
entries are complete and not left as instructional placeholders.



#### **2. Testing Goals**
- Validate Correct Architecture Scheduling: Confirm that 100% of amd64 and arm64 VMs are automatically placed on worker nodes with the matching CPU architecture.

- Verify Live Migration: Successfully migrate running VMs between same-arch nodes (x86 to x86, ARM to ARM).

- Verify Multi-Method Provisioning: Achieve 100% success rate for VM creation using both golden image DataSources and custom Qcow2 images across both architectures.

#### **3. Test Strategy**

The following test strategy considerations must be reviewed and addressed. Mark "Y" if applicable,
"N/A" if not applicable (with justification in Comments). Empty cells indicate incomplete review.

| Item | Description | Applicable (Y/N or N/A) | Comments |
| :----------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------- | :---------------------- | :------- |
| Functional Testing | Validates that the VM scedules and live migrates on corrcet architecture node stories | Yes | |
| Automation Testing | Ensures test cases are automated for continuous integration and regression coverage | Yes | |
| Performance Testing | Validates feature performance meets requirements (latency, throughput, resource usage) | N/A | |
| Security Testing | Verifies security requirements, RBAC, authentication, authorization, and vulnerability scanning | N/A | |
| Usability Testing | Validates user experience, UI/UX consistency, and accessibility requirements. Does the feature require UI? If so, ensure the UI aligns with the requirements | Yes | |
Comment on lines +81 to +90
Copy link

@coderabbitai coderabbitai bot Jan 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Clean up typos and normalize applicability values.
Line 86 has spelling errors (“scedules”, “corrcet”). Also the table instructs Y/N or N/A, but values are “Yes”; please standardize to the documented format.

🤖 Prompt for AI Agents 
In `@stps/sig-virt/multiarch_support.md` around lines 81 - 90, Fix the typos and
normalize applicability values in the test-strategy table: correct "scedules" to
"schedules" and "corrcet" to "correct" in the "Functional Testing" Description,
and change all "Yes"/"No" entries to the documented "Y"/"N/A" format (e.g.,
replace "Yes" with "Y", keep "N/A" as-is), ensuring the "Applicable (Y/N or
N/A)" column for each row (Functional Testing, Automation Testing, Performance
Testing, Security Testing, Usability Testing) uses the standardized values and
add justification text in the "Comments" column where a cell is marked "N/A".

| Compatibility Testing | Ensures feature works across supported platforms, versions, and configurations | N/A | |
| Regression Testing | Verifies that new changes do not break existing functionality | Yes | |
| Upgrade Testing | Validates upgrade paths from previous versions, data migration, and configuration preservation | N/A | |
| Backward Compatibility Testing | Ensures feature maintains compatibility with previous API versions and configurations | N/A | |
| Dependencies | Dependent on deliverables from other components/products? Identify what is tested by which team. | N/A | |
| Cross Integrations | Does the feature affect other features/require testing by other components? Identify what is tested by which team. | N/A | |
| Monitoring | Does the feature require metrics and/or alerts? | N/A | |
| Cloud Testing | Does the feature require multi-cloud platform testing? Consider cloud-specific features. | N/A | |

#### **4. Test Environment**


| Environment Component | Configuration | Specification Examples |
| :-------------------------------------------- | :-------------------- | :-------------------------------------------------------------------------------------------- |
| **Cluster Topology** | MultiArch cluster | 3 control-plane and 4 worker nodes |
| **OCP & OpenShift Virtualization Version(s)** | OCP 4.21, CNV-4.21 | OCP 4.21 and OpenShift Virtualization 4.21 |
| **CPU Virtualization** | Multi-arch cluster | 3 amd64 control-plane, 2 amd64 workers, and 2 arm64 workers |
| **Compute Resources** | N/A | [e.g., Minimum per worker node: 8 vCPUs, 32GB RAM] |
| **Special Hardware** | N/A | [e.g., Specific NICs for SR-IOV, GPU etc.] |
| **Storage** | io2-csi storage class | AWS EBS io2 CSI driver |
| **Network** | N/A | [e.g., OVN-Kubernetes (default), Secondary Networks, Network Plugins, IPv4, IPv6, dual-stack] |
| **Required Operators** | N/A | [e.g., NMState Operator] |
| **Platform** | AWS | AWS for Arm nodes. |
| **Special Configurations** | N/A | [e.g., Disconnected/air-gapped cluster, Proxy environment, FIPS mode enabled] |
Comment on lines +108 to +114
Copy link

@coderabbitai coderabbitai bot Jan 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

Replace remaining placeholder examples in Test Environment.
Several rows still contain [e.g., ...] examples. Please replace with concrete values or mark N/A with rationale so the environment requirements are actionable.

🤖 Prompt for AI Agents 
In `@stps/sig-virt/multiarch_support.md` around lines 108 - 114, The Test
Environment table still contains placeholder examples in rows like "Compute
Resources", "Special Hardware", "Network", and "Special Configurations"—replace
each "[e.g., ...]" with concrete, actionable values (e.g., for Compute
Resources: "Minimum per worker node: 8 vCPUs, 32GB RAM"; for Special Hardware:
"SR-IOV NICs: Mellanox ConnectX-5" or state "N/A - no special NICs required for
tests"; for Network: specify plugin and IP stack such as "OVN-Kubernetes,
IPv4-only"; for Special Configurations: list "air-gapped: false" or provide
proxy/FIPS details) or mark the cell as "N/A" and add a short rationale
explaining why it's not applicable so the "Compute Resources", "Special
Hardware", "Storage", "Network", "Required Operators", "Platform", and "Special
Configurations" rows are all actionable.


#### **4.1. Testing Tools & Frameworks**

<!-- Document any **new or additional** testing tools, frameworks, or infrastructure required specifically
for this feature. **Note:** Only list tools that are **new** or **different** from standard testing infrastructure.
Leave empty if using standard tools. -->

| Category | Tools/Frameworks |
| :----------------- | :---------------- |
| **Test Framework** | MultiArch cluster |
| **CI/CD** | |
| **Other Tools** | |

#### **5. Entry Criteria**

The following conditions must be met before testing can begin:

- [ ] Requirements and design documents are **approved and merged**
- [ ] Test environment can be **set up and configured** (see Section II.4 - Test Environment)
- [ ] Multi-CPU architecture support enabled in openshift-virtualization repo

Comment on lines +128 to +135
Copy link

@coderabbitai coderabbitai bot Jan 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cat -n stps/sig-virt/multiarch_support.md | sed -n '120,140p'

Repository: RedHatQE/openshift-virtualization-tests-design-docs

Length of output: 980

🏁 Script executed:

rg -i "(github|issue|pr|pull request|#[0-9])" stps/sig-virt/multiarch_support.md

Repository: RedHatQE/openshift-virtualization-tests-design-docs

Length of output: 2837

🏁 Script executed:

rg -i "multi-cpu|multiarch" stps/sig-virt/multiarch_support.md -B 2 -A 2

Repository: RedHatQE/openshift-virtualization-tests-design-docs

Length of output: 1206

🏁 Script executed:

head -50 stps/sig-virt/multiarch_support.md

Repository: RedHatQE/openshift-virtualization-tests-design-docs

Length of output: 6290

Add explicit tracking references to Entry Criteria items.

Line 134 mentions "Multi-CPU architecture support enabled" but lacks a reference to the specific tracking issue. Link this item to the relevant Jira tracking issue (e.g., CNV-26818) or the enhancement document. While this document is in Draft status, Entry Criteria items should clearly reference where their completion is tracked.

🤖 Prompt for AI Agents 
In @stps/sig-virt/multiarch_support.md around lines 128 - 135, Update the "Entry
Criteria" checklist by adding an explicit tracking reference for the "Multi-CPU
architecture support enabled in openshift-virtualization repo" item: change that
bullet to include the relevant Jira/enhancement link (e.g., reference
[CNV-26818](https://issues.redhat.com/browse/CNV-26818) or the enhancement
document) so the completion of this criterion is clearly tracked; ensure the
text uses the same bullet label ("Multi-CPU architecture support enabled in
openshift-virtualization repo") and simply appends the tracking URL or issue key
in parentheses or as a markdown link.

#### **6. Risks**

<!-- Document specific risks for this feature. If a risk category is not applicable, mark as "N/A" with
justification in mitigation strategy. -->

<!-- **Note:** Empty "Specific Risk" cells mean this must be filled. "N/A" means explicitly not applicable
with justification. -->

| Risk Category | Specific Risk for This Feature | Mitigation Strategy | Status |
| :------------------- | :------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------- | :----- |
| Timeline/Schedule | Code Freeze on Jan 12th | [Your specific mitigation, e.g., "Prioritize P1 scenarios, automate in parallel"] | [ ] |
| Test Coverage | enable multi-arch cluster support is under WIP | PR https://github.com/RedHatQE/openshift-virtualization-tests/pull/3147 | [ ] |
| Test Environment | For testing Live Migration we need 2 ARM64 nodes and two AMD64 nodes on a cluster current jenkins job deploys cluster with single ARM64 node | https://issues.redhat.com/browse/CNV-73894 | [ ] |
| Untestable Aspects | [List what cannot be tested, e.g., "Production scale with 10k VMs"] | [Your mitigation, e.g., "Test at smaller scale, extrapolate results, prod monitoring"] | [ ] |
| Resource Constraints | [Describe resource issues, e.g., "Only 1 QE assigned, feature spans 3 components"] | [Your mitigation, e.g., "Focus automation on critical paths, coordinate with dev for testing"] | [ ] |
| Dependencies | [Describe dependency risks, e.g., "Depends on Storage team delivering feature X"] | [Your mitigation, e.g., "Coordinate with Storage QE, have backup test plan"] | [ ] |
| Other | [Any other specific risks] | [Mitigation strategy] | [ ] |

#### **7. Known Limitations**

Testing on Container Disk VM is limited since, there's no defaulting of the architecture based on the containerdisk arch at the moment so VM won't schedule on expected architecture node unless manually providing spec.template.spec.architecture in the VM


### **III. Test Scenarios & Traceability**

Copy link

@geetikakay geetikakay Feb 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably a windows tests
Windows ARM incompatibility | Attempt to create Windows VM on ARM node when only x86 image available. Verify graceful failure with clear error message | Tier 2 | P1 | |

This section links requirements to test coverage, enabling reviewers to verify all requirements are
tested.

| Requirement ID | Requirement Summary | Test Scenario(s) | Tier | Priority |
| :------------- | :------------------ | :----------------------------------------------------------------------------- | :----- | :------- |
| [CNV-72102] | | Deploy and Test with a Multi-Arch cluster with 4.21 | Tier 2 | P2 |
| [CNV-74480] | | Test updating amd64 cpuModel in HCO and check arm64 VM creations on ARM nodes. | Tier 2 | P0 |
| [CNV-75737] | | Run Tier2 Tests on Multi-Arch Clusters (ARM64 and AMD64) | Tier 2 | P1 |
| [CNV-74481] | | Update Tier2 automation to handle Multi-Arch scenarios | Tier 2 | P2 |
| [CNV-33896] | | Run Conformance Tests on multi-arch cluster (ARM64 and AMD64) | Tier 1 | P1 |
Comment on lines +159 to +170
Copy link

@coderabbitai coderabbitai bot Jan 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Populate Requirement Summary column in traceability matrix.

The "Requirement Summary" column (lines 164-170) is completely empty. Each row must include a brief summary of the requirement from the referenced JIRA ticket (e.g., "Validate AMD64 VM scheduling," "Enable ARM64 node support," etc.) to enable reviewers to verify traceability without external system access.

🧰 Tools
🪛 LanguageTool

[grammar] ~168-~168: Ensure spelling is correct
Context: ...V-75737] | | Run Tier2 Tests on Multi-Arch Clusters (ARM64 and...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

[grammar] ~169-~169: Ensure spelling is correct
Context: ...4481] | | Update Tier2 automation to handle Multi-Arch scenari...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

🤖 Prompt for AI Agents 
In @stps/sig-virt/multiarch_support.md around lines 159 - 170, The Requirement
Summary column in the traceability matrix is empty for the listed tickets;
update the table rows for [CNV-72102], [CNV-74480], [CNV-75737], [CNV-74481],
and [CNV-33896] by adding a one-line summary for each JIRA (e.g., CNV-72102:
"Deploy and validate multi-arch cluster on 4.21", CNV-74480: "Validate amd64
cpuModel update and arm64 VM scheduling", CNV-75737: "Execute Tier2 tests across
ARM64 and AMD64", CNV-74481: "Extend Tier2 automation for multi-arch scenarios",
CNV-33896: "Run conformance tests on ARM64 and AMD64"); ensure each summary is
concise, matches the ticket intent, and placed in the Requirement Summary column
for easy reviewer traceability.


Comment on lines +159 to +171
Copy link

@coderabbitai coderabbitai bot Jan 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

find . -name "multiarch_support.md" -path "*/sig-virt/*" 2>/dev/null | head -20

Repository: RedHatQE/openshift-virtualization-tests-design-docs

Length of output: 131

🏁 Script executed:

cat -n ./stps/sig-virt/multiarch_support.md | sed -n '155,175p'

Repository: RedHatQE/openshift-virtualization-tests-design-docs

Length of output: 1686

Populate the Requirement Summary column in the traceability matrix.

All entries in the "Requirement Summary" column (lines 166–170) are empty. This breaks the traceability chain described in the section header, which explicitly states the purpose is to "link requirements to test coverage, enabling reviewers to verify all requirements are tested." Each CNV Jira ID must have a corresponding summary that describes what the requirement aims to achieve. Without these summaries, reviewers cannot verify that test scenarios adequately cover each requirement. Add concise requirement descriptions for each entry.

🧰 Tools
🪛 LanguageTool

[grammar] ~168-~168: Ensure spelling is correct
Context: ...V-75737] | | Run Tier2 Tests on Multi-Arch Clusters (ARM64 and...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

[grammar] ~169-~169: Ensure spelling is correct
Context: ...4481] | | Update Tier2 automation to handle Multi-Arch scenari...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

🤖 Prompt for AI Agents 
In @stps/sig-virt/multiarch_support.md around lines 159 - 171, The Requirement
Summary column in the "III. Test Scenarios & Traceability" table is empty for
the listed CNV Jira IDs; fill each row's Requirement Summary with a concise
one-line description of the requirement for CNV-72102, CNV-74480, CNV-75737,
CNV-74481, and CNV-33896 so the traceability matrix links requirement to test
coverage (e.g., CNV-72102: "Support deployment and validation of multi-arch
(ARM64/AMD64) clusters on 4.21", CNV-74480: "Allow amd64 cpuModel updates in HCO
while ensuring VMs schedule/run on ARM nodes", CNV-75737: "Execute Tier2
automated tests across ARM64 and AMD64 nodes", CNV-74481: "Extend Tier2
automation to detect and handle multi-arch node differences", CNV-33896: "Run
conformance test suite on multi-arch clusters to verify platform
compatibility"). Ensure each summary is short, specific, and directly maps to
the existing Test Scenario for reviewers.

---

### **IV. Sign-off and Approval**

This Software Test Plan requires approval from the following stakeholders:

* **Reviewers:**
- dshchedr
- vsibirsk
- kbidarkar
- SiboWang1997
- jerry7z
- SamAlber
* **Approvers:**
- dshchedr
- vsibirsk