Conversation
WalkthroughAdds a new QE Software Test Plan for OpenShift Virtualization that defines multi-architecture VM creation and same-architecture live-migration testing in mixed AMD64/ARM64 clusters, including scope, topology, environments, tools, entry/exit criteria, risks, limitations, traceability, and sign-off. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 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
Container Operations
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. |
openshift-virtualization-qe-bot
requested review from
SamAlber,
jerry7z,
kbidarkar and
vsibirsk
|
/wip |
openshift-virtualization-qe-bot-3
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 Fix all issues with AI agents
In @stps/sig-virt/multiarch_support.md:
- Around line 38-46: The "Technology and Design Review" table marks all checks
as done but contains generic templated notes; update each row (Developer
Handoff/QE Kickoff, Technology Challenges, Test Environment Needs, API
Extensions, Topology Considerations) with concrete, multi-arch-specific details
(e.g., meeting attendees/outcomes for Developer Handoff/QE Kickoff; specific
architecture challenges and mitigations for Technology Challenges; required
emulator/hardware/configuration and test matrix for Test Environment Needs;
precise API changes, backward-compat concerns and test cases for API Extensions;
cluster/network impact and validation strategy for Topology Considerations), or
if any of those were not actually completed, change the corresponding Done
checkbox from [V] to unchecked to reflect incomplete review.
- Line 109: Update the American English abbreviation style by adding periods to
"etc" in the table entries: change the text "e.g., Specific NICs for SR-IOV, GPU
etc" (and the other occurrence on line 113) to "e.g., Specific NICs for SR-IOV,
GPU etc." so both table cells use "etc." consistently.
- Around line 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.
- Line 3: Fix the title line by correcting the typo "craetion" to "creation",
change "multi arch" to "multi-arch", and remove or fix the stray trailing
asterisks so the header is valid Markdown; e.g. update the header string "## VM
craetion and Live Migration on a multi arch cluster - Quality Engineering
Plan**" to a properly formatted header such as "## VM creation and Live
Migration on a multi-arch cluster - Quality Engineering Plan".
- Around line 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.
- Around line 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.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
stps/sig-virt/multiarch_support.md
🧰 Additional context used
🪛 LanguageTool
stps/sig-virt/multiarch_support.md
[grammar] ~3-~3: Ensure spelling is correct
Context: ...t-virtualization-tests Test plan ## VM craetion and Live Migration on a multi arch clus...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~3-~3: Use a hyphen to join words.
Context: ...M craetion and Live Migration on a multi arch cluster - Quality Engineering Plan*...
(QB_NEW_EN_HYPHEN)
[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)
[style] ~109-~109: In American English, abbreviations like “etc.” require a period.
Context: ... | [e.g., Specific NICs for SR-IOV, GPU etc] ...
(ETC_PERIOD)
[style] ~113-~113: In American English, abbreviations like “etc.” require a period.
Context: ... | [e.g., Bare metal, AWS, Azure, GCP etc] ...
(ETC_PERIOD)
[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)
🔇 Additional comments (1)
stps/sig-virt/multiarch_support.md (1)
116-126: No action needed—the Testing Tools & Frameworks section is correctly empty per documented instructions.The section explicitly states to "Leave empty if using standard tools" (lines 119-120). Based on Section 3 (Test Strategy), this feature uses standard functional and automation testing approaches. The empty table correctly reflects this and aligns with the template's guidance.
| **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 | | ||
|
|
There was a problem hiding this comment.
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.
| **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.
stps/sig-virt/multiarch_support.md
Outdated
| | **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] | |
There was a problem hiding this comment.
Add periods to abbreviations in American English.
Lines 109 and 113 contain "etc" without periods; should be "etc." per American English style guidelines.
✏️ Proposed fixes
-| **Compute Resources** | N/A | [e.g., Minimum per worker node: 8 vCPUs, 32GB RAM] |
+| **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] |
+| **Special Hardware** | N/A | [e.g., Specific NICs for SR-IOV, GPU etc.] |
-| **Platform** | N/A | [e.g., Bare metal, AWS, Azure, GCP etc] |
+| **Platform** | N/A | [e.g., Bare metal, AWS, Azure, GCP etc.] |Also applies to: 113-113
🧰 Tools
🪛 LanguageTool
[style] ~109-~109: In American English, abbreviations like “etc.” require a period.
Context: ... | [e.g., Specific NICs for SR-IOV, GPU etc] ...
(ETC_PERIOD)
🤖 Prompt for AI Agents
In @stps/sig-virt/multiarch_support.md at line 109, Update the American English
abbreviation style by adding periods to "etc" in the table entries: change the
text "e.g., Specific NICs for SR-IOV, GPU etc" (and the other occurrence on line
113) to "e.g., Specific NICs for SR-IOV, GPU etc." so both table cells use
"etc." consistently.
| #### **5. Entry Criteria** | ||
|
|
||
| The following conditions must be met before testing can begin: | ||
|
|
||
| - [ ] Requirements and design documents are **approved and merged** | ||
| - [V] Test environment can be **set up and configured** (see Section II.4 - Test Environment) | ||
| - [ ] Multi-CPU architecture support enabled in openshift-virtualization repo | ||
|
|
There was a problem hiding this comment.
🧩 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.mdRepository: 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 2Repository: RedHatQE/openshift-virtualization-tests-design-docs
Length of output: 1206
🏁 Script executed:
head -50 stps/sig-virt/multiarch_support.mdRepository: 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.
| ### **III. Test Scenarios & Traceability** | ||
|
|
||
| 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 | | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "multiarch_support.md" -path "*/sig-virt/*" 2>/dev/null | head -20Repository: 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.
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Fix all issues with AI agents
In @stps/sig-virt/multiarch_support.md:
- Around line 116-126: Populate the "4.1. Testing Tools & Frameworks" table by
stating whether standard testing infra is sufficient or listing any additional
tools required for multi-arch validation; specifically either add the sentence
"Standard openshift-virtualization testing infrastructure used; no additional
tools required." or, if extra tooling is needed, list items such as "ARM64 test
runners (qemu-user-static or hardware runners), cross-architecture CI jobs,
platform-specific debuggers" under the appropriate table rows (**Test
Framework**, **CI/CD**, **Other Tools**) so the section is no longer empty.
- Around line 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.
- Around line 136-152: The table has placeholder text in the "Test Environment",
"Untestable Aspects", "Resource Constraints", and "Dependencies" rows—replace
each placeholder cell with concrete risk descriptions and matching mitigation
steps (e.g., for "Test Environment" describe required hardware or cluster
constraints and mitigation like reserving nodes or emulating; for "Untestable
Aspects" list scenarios that cannot be validated and mitigation like scale
extrapolation and monitoring; for "Resource Constraints" name people/CI limits
and mitigation such as prioritization or cross-team support; for "Dependencies"
list external teams/PRs and mitigation like sync points or fallback plans) and
populate the "Status" checkbox for each row after stakeholder review/approval;
use the "Code Freeze on Jan 12th" and the PR link example as models for
specificity and include any relevant links or owners.
- Around line 83-97: The table rows labeled "Dependencies" and "Cross
Integrations" currently contain placeholder text; replace them with concrete
assessments naming the specific teams and components (e.g., for Dependencies:
"Depends on CNV storage team for DataSource support; requires multi-arch cluster
provisioning from infra team"; for Cross Integrations: "Storage team tests
DataSource provisioning; Network team validates multi-arch networking; CI team
verifies multi-arch image build and deployment"). Ensure each entry is concise,
actionable, and maps the test responsibility to the owning team or component so
the test strategy clearly shows who validates each dependency and integration.
🧹 Nitpick comments (4)
stps/sig-virt/multiarch_support.md (4)
1-3: Fix formatting issues in title.Line 3 has an extra closing asterisk, and "multi arch" should be hyphenated as "multi-arch" per markdown style conventions.
- ## VM creation and Live Migration on a multi arch cluster - Quality Engineering Plan** + ## VM creation and Live Migration on a multi-arch cluster - Quality Engineering Plan
128-134: Clarify Entry Criteria completion timeline.Lines 132 and 134 have unchecked criteria, which is appropriate for a WIP document. However, the STP should include a note indicating the planned date or milestone for completing these entry criteria before formal testing begins.
99-114: Clean up placeholder text in N/A test environment entries.Lines 108 and 111-114 have "N/A" entries with bracketed example text (e.g., "[e.g., Minimum per worker node: 8 vCPUs, 32GB RAM]"). Remove the bracket notation or replace with actual values if applicable. The instructions at line 101 state "N/A means explicitly not applicable"—the examples should not remain in the final document.
154-157: Consider expanding Known Limitations with workarounds or resolution timeline.The Known Limitations section is concise and clear. For completeness, consider adding:
- Workaround: "Manually specify
spec.template.spec.architecturein VM YAML to override auto-scheduling"- Expected resolution: Reference to related GitHub/JIRA issue tracking this limitation
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
stps/sig-virt/multiarch_support.md
🧰 Additional context used
🪛 LanguageTool
stps/sig-virt/multiarch_support.md
[grammar] ~3-~3: Use a hyphen to join words.
Context: ...M creation and Live Migration on a multi arch cluster - Quality Engineering Plan*...
(QB_NEW_EN_HYPHEN)
[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)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: can-be-merged
- GitHub Check: tox
- GitHub Check: can-be-merged
- GitHub Check: can-be-merged
- GitHub Check: tox
- GitHub Check: can-be-merged
stps/sig-virt/multiarch_support.md
Outdated
| | Item | Description | Applicable (Y/N or N/A) | Comments | | ||
| | :----------------------------- | :----------------------------------------------------------------------------------------------------------------- | :---------------------- | :------- | | ||
| | Functional Testing | Yes | | | | ||
| | Automation Testing | Yes | | | | ||
| | Performance Testing | N/A | | | | ||
| | Security Testing | N/A | | | | ||
| | Usability Testing | Yes | | | | ||
| | Compatibility Testing | N/A | | | | ||
| | Regression Testing | Yes | | | | ||
| | Upgrade Testing | N/A | | | | ||
| | Backward Compatibility Testing | N/A | | | | ||
| | Dependencies | Dependent on deliverables from other components/products? Identify what is tested by which team. | | | | ||
| | Cross Integrations | Does the feature affect other features/require testing by other components? Identify what is tested by which team. | | | | ||
| | Monitoring | Yes | | | | ||
| | Cloud Testing | N/A | | | |
There was a problem hiding this comment.
Clarify Dependencies and Cross Integrations in test strategy.
Lines 94-95 (Dependencies and Cross Integrations rows) contain incomplete descriptions with placeholder text. Replace with actual assessments:
- Dependencies: Identify specific dependencies (e.g., "Depends on CNV storage team for DataSource support", "Requires multi-arch cluster provisioning from infra team")
- Cross Integrations: Specify which components/teams are responsible for testing interactions (e.g., "Storage team tests DataSource provisioning," "Network team validates multi-arch networking")
🤖 Prompt for AI Agents
In @stps/sig-virt/multiarch_support.md around lines 83 - 97, The table rows
labeled "Dependencies" and "Cross Integrations" currently contain placeholder
text; replace them with concrete assessments naming the specific teams and
components (e.g., for Dependencies: "Depends on CNV storage team for DataSource
support; requires multi-arch cluster provisioning from infra team"; for Cross
Integrations: "Storage team tests DataSource provisioning; Network team
validates multi-arch networking; CI team verifies multi-arch image build and
deployment"). Ensure each entry is concise, actionable, and maps the test
responsibility to the owning team or component so the test strategy clearly
shows who validates each dependency and integration.
stps/sig-virt/multiarch_support.md
Outdated
| #### **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** | | | ||
| | **CI/CD** | | | ||
| | **Other Tools** | | |
There was a problem hiding this comment.
Populate or clarify the Testing Tools & Frameworks section.
Section II.4.1 is completely empty. The instructions state to "leave empty if using standard tools," but this section should explicitly document whether standard testing infrastructure is sufficient or if new/different tools are required for multi-arch testing (e.g., special ARM64 test runners, platform-specific tools).
Even if standard tools suffice, add a note: "Standard openshift-virtualization testing infrastructure used; no additional tools required."
🤖 Prompt for AI Agents
In @stps/sig-virt/multiarch_support.md around lines 116 - 126, Populate the
"4.1. Testing Tools & Frameworks" table by stating whether standard testing
infra is sufficient or listing any additional tools required for multi-arch
validation; specifically either add the sentence "Standard
openshift-virtualization testing infrastructure used; no additional tools
required." or, if extra tooling is needed, list items such as "ARM64 test
runners (qemu-user-static or hardware runners), cross-architecture CI jobs,
platform-specific debuggers" under the appropriate table rows (**Test
Framework**, **CI/CD**, **Other Tools**) so the section is no longer empty.
stps/sig-virt/multiarch_support.md
Outdated
| #### **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 | [Describe environment risks, e.g., "Requires GPU hardware, limited availability"] | [Your mitigation, e.g., "Reserve GPU nodes early, schedule tests in advance"] | [ ] | | ||
| | 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] | [ ] | |
There was a problem hiding this comment.
Complete risk assessments and mitigation strategies.
Rows for Test Environment, Untestable Aspects, Resource Constraints, and Dependencies (lines 148-151) contain placeholder text that must be replaced with actual risk assessments and mitigation strategies. Additionally, the Status column should be populated once risks are reviewed and approved by stakeholders.
Reference lines 146-147 as examples of appropriate specificity (e.g., "Code Freeze on Jan 12th," actual PR link).
🤖 Prompt for AI Agents
In @stps/sig-virt/multiarch_support.md around lines 136 - 152, The table has
placeholder text in the "Test Environment", "Untestable Aspects", "Resource
Constraints", and "Dependencies" rows—replace each placeholder cell with
concrete risk descriptions and matching mitigation steps (e.g., for "Test
Environment" describe required hardware or cluster constraints and mitigation
like reserving nodes or emulating; for "Untestable Aspects" list scenarios that
cannot be validated and mitigation like scale extrapolation and monitoring; for
"Resource Constraints" name people/CI limits and mitigation such as
prioritization or cross-team support; for "Dependencies" list external teams/PRs
and mitigation like sync points or fallback plans) and populate the "Status"
checkbox for each row after stakeholder review/approval; use the "Code Freeze on
Jan 12th" and the PR link example as models for specificity and include any
relevant links or owners.
| ### **III. Test Scenarios & Traceability** | ||
|
|
||
| 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 | |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@stps/sig-virt/multiarch_support.md`:
- Line 113: Update the table row labeled "Platform" in multiarch_support.md to
replace the "N/A" value with "AWS" so it correctly reflects that AWS is the
provider for all ARM nodes in the multi-arch test environment; locate the row
containing the "**Platform**" header and change its second column from "N/A" to
"AWS".
- Line 133: Unmark the "[V] Test environment can be **set up and configured**
(see Section II.4 - Test Environment)" checkpoint until the second arm64 node is
actually added, or alternatively update Section II.4 (the "Test Environment"
description that currently states "2 amd64 workers, and 2 arm64 workers") to
reflect the current single arm64 node and adjust test scope accordingly; locate
the checklist entry and the Section II.4 text in multiarch_support.md and either
remove the check mark and add a TODO noting the pending manual ARM node
addition, or change the environment description and any dependent test
coverage/acceptance criteria to match one arm64 worker.
♻️ Duplicate comments (7)
stps/sig-virt/multiarch_support.md (7)
3-3: Fix title formatting.The title still has "multi arch" instead of "multi-arch" and has stray trailing asterisks. This was flagged in previous reviews.
38-46: Complete the Technology and Design Review with specific details.All items are marked as done, but the "Details/Notes" contain generic template text (e.g., line 42: "Critical for identifying untestable aspects early"). This was flagged in previous reviews and remains unresolved. Either provide concrete multi-arch-specific details for each row or uncheck items that weren't fully reviewed.
83-97: Fix Test Strategy table formatting.The table structure is incorrect: values like "Yes" and "N/A" are placed in the "Description" column instead of the "Applicable (Y/N or N/A)" column. This was explicitly flagged by vsibirsk in previous reviews. Additionally, the "Dependencies" and "Cross Integrations" rows still contain placeholder/incomplete descriptions.
Based on learnings, vsibirsk noted wrong table filling with Y/N/A values in wrong column.
🔧 Example fix for table structure
-| Functional Testing | Yes | | | +| Functional Testing | Core VM scheduling and migration validation on multi-arch cluster | Y | | -| Automation Testing | Yes | | | +| Automation Testing | Automated test suite covering VM creation, scheduling, and migration scenarios | Y | | -| Dependencies | Dependent on deliverables from other components/products? Identify what is tested by which team. | | | +| Dependencies | Multi-arch cluster provisioning (infra team); ARM64 node availability (CI team); DataSource support (storage team) | Y | Coordinate with infra/CI for environment |
116-127: Document testing tools or clarify standard tooling use.The Testing Tools & Frameworks section is completely empty. This was flagged in previous reviews. Either document any multi-arch-specific tools required, or explicitly state that standard OpenShift virtualization testing infrastructure is sufficient.
148-151: Complete risk assessments with actual project risks.Rows for "Test Environment", "Untestable Aspects", "Resource Constraints", and "Dependencies" still contain placeholder instructional text. These must be replaced with actual risk assessments and mitigation strategies specific to multi-arch testing. For example, vsibirsk noted the test environment currently lacks sufficient ARM nodes for migration testing—this should be documented as a Test Environment risk.
Based on learnings, vsibirsk flagged the lack of additional ARM nodes as an environment concern.
💡 Example risk entries
-| Test Environment | [Describe environment risks, e.g., "Requires GPU hardware, limited availability"] | [Your mitigation, e.g., "Reserve GPU nodes early, schedule tests in advance"] | [ ] | +| Test Environment | Current setup has only 1 ARM node; requires manual addition of 2nd ARM node for migration testing | Automate ARM node provisioning in CI; coordinate with infra team for additional resources | [ ] |
164-170: Populate the Requirement Summary column.The "Requirement Summary" column is completely empty for all CNV Jira IDs. This was flagged multiple times in previous reviews as a critical issue. The section explicitly states its purpose is to "link requirements to test coverage, enabling reviewers to verify all requirements are tested"—this is impossible without requirement summaries. Add concise one-line descriptions for each Jira ticket.
58-60: Standardize architecture terminology.The document inconsistently refers to architectures as "AMD64 and ARM64" (line 58) versus "
amd64" and "arm64" (line 60). Per vsibirsk's previous feedback, use the lowercase forms (amd64andarm64) consistently throughout to match KubeVirt conventions.Based on learnings, vsibirsk requested consistent arch naming using lowercase forms.
📝 Proposed consistency fix
-- 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` architectures 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 each architecture and ensure they always land on the right nodes.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
stps/sig-virt/multiarch_support.md
🧰 Additional context used
🪛 LanguageTool
stps/sig-virt/multiarch_support.md
[grammar] ~3-~3: Use a hyphen to join words.
Context: ...M creation and Live Migration on a multi arch cluster - Quality Engineering Plan*...
(QB_NEW_EN_HYPHEN)
[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)
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
Signed-off-by: akri3i <guptaakriti70@gmail.com>
for more information, see https://pre-commit.ci
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@stps/sig-virt/multiarch_support.md`:
- Around line 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.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
stps/sig-virt/multiarch_support.md
🧰 Additional context used
🪛 LanguageTool
stps/sig-virt/multiarch_support.md
[grammar] ~3-~3: Use a hyphen to join words.
Context: ...M creation and Live Migration on a multi arch cluster - Quality Engineering Plan*...
(QB_NEW_EN_HYPHEN)
[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)
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
| - 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. |
There was a problem hiding this comment.
🛠️ 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.
|
/wip cancel |
openshift-virtualization-qe-bot-2
changed the title
Co-authored-by: vsibirsk <57763370+vsibirsk@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Fix all issues with AI agents
In `@stps/sig-virt/multiarch_support.md`:
- Around line 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.
- 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".
- Around line 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.
- Around line 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".
♻️ Duplicate comments (6)
stps/sig-virt/multiarch_support.md (6)
3-3: Fix title formatting and hyphenation.
The header still has “multi arch” and trailing**, which breaks Markdown rendering.
63-68: Remove placeholder note and complete Out-of-Scope items.
This section still includes template text and an example row; it needs actual exclusions and rationale.
116-126: Populate the Testing Tools & Frameworks table.
This section is still effectively empty and uses a non-tool value (“MultiArch cluster”). Clarify standard tooling or list any additional tools.
132-134: Add a tracking reference to the Entry Criteria item.
“Multi-CPU architecture support enabled…” should link to the tracking Jira or enhancement.
149-151: Complete risk details and mitigation.
These rows still contain placeholder text and need concrete risks/mitigations.
164-170: Fill the Requirement Summary column.
All entries are empty, which breaks traceability to the test scenarios.
| **Document Conventions (if applicable):** [Define acronyms or terms specific to this document] | ||
| - VM : Virtual Machine |
There was a problem hiding this comment.
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.
|
|
||
| #### **1. Scope of Testing** | ||
|
|
||
| This test plan checks if VMs schedules and live migrates correctly on a mixed architecture cluster |
There was a problem hiding this comment.
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".
| 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 | | |
There was a problem hiding this comment.
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".
| | **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] | |
There was a problem hiding this comment.
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.
|
|
||
|
|
||
| ### **III. Test Scenarios & Traceability** | ||
|
|
There was a problem hiding this comment.
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 | |
8 participants
STP Metadata
VEP issue:
What this PR does
Special notes for your reviewer
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.