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:
📝 WalkthroughWalkthroughAdds a new OpenShift Virtualization Quality Engineering Plan document ( Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 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. |
![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
🤖 Fix all issues with AI agents
In @stps/sig-iuo/golden_image_multiarch_support.md:
- Line 25: The term label "Muliarch FG" contains a typo; update it to "MultiArch
FG" to match the existing "MultiArch cluster" terminology and keep consistency
with the feature gate name `enableMultiArchBootImageImport` in the same row
(change the display string for that table cell only).
- Around line 160-169: The out-of-scope table rows (e.g., "Update existing VM",
"Performance Testing", "Security Testing", "Usability testing", "Compatibility",
"Templates creation & utilization", "Imports & datasource new API", "Testing
with s390x architecture") are missing required PM/Lead sign-offs; update each
checkbox from "[ ]" to "[x] Name/Date" with the actual stakeholder name and date
for every listed item, and if a sign-off cannot be obtained immediately add a
short escalation note next to the item (e.g., "Pending: escalate to PM/Lead -
Date") to surface the risk per the document guidance.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
stps/sig-iuo/golden_image_multiarch_support.md
🧰 Additional context used
🪛 LanguageTool
stps/sig-iuo/golden_image_multiarch_support.md
[style] ~53-~53: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...usters.
2. As a cluster admin, I want to define custom golden images with multi-...
(REP_WANT_TO_VB)
[style] ~278-~278: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... US2 | As a cluster admin, I want to define custom golden images with multi-...
(REP_WANT_TO_VB)
[style] ~279-~279: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... | As a VM creator/cluster admin, I want to create VMs / custom golden images for s...
(REP_WANT_TO_VB)
[style] ~280-~280: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... US2, US3 | As a cluster admin, I want to define custom golden images for specifi...
(REP_WANT_TO_VB)
[style] ~283-~283: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... US2 | As a cluster admin, I want to define custom golden images with multi-...
(REP_WANT_TO_VB)
[style] ~287-~287: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... | As a VM creator/cluster admin, I want to create VMs / custom golden images for s...
(REP_WANT_TO_VB)
[style] ~288-~288: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...US3 | As a VM creator/cluster admin, I want to create VMs / define custom golden image...
(REP_WANT_TO_VB)
🔇 Additional comments (9)
stps/sig-iuo/golden_image_multiarch_support.md (9)
43-57: Requirements review is comprehensive.The checklist covers all essential aspects: requirements, value propositions, use cases, testability, acceptance criteria, and NFRs. The user stories are well-articulated with clear value statements.
125-144: Test goals are well-defined and prioritized.The functional, monitoring, backward compatibility, and upgrade goals are specific, measurable, and properly prioritized (P0/P1). Good coverage of all key aspects of the feature.
176-190: Test strategy coverage is comprehensive.The test strategy table appropriately covers functional, automation, upgrade, and backward compatibility testing. The N/A justifications for performance, security, compatibility, and regression testing are reasonable given the feature scope.
248-258: Known limitations are well-documented.The three limitations are clearly stated with appropriate scope:
- Existing VMs not automatically updated
- Platform variant formats not supported
- Architecture validation is user responsibility
These set clear expectations for users and testers.
275-288: Excellent requirements-to-test traceability.The traceability matrix provides clear mapping from user stories to test scenarios with appropriate tier and priority assignments. Each requirement is covered by at least one test scenario, ensuring comprehensive coverage.
1-301: Overall: Well-structured test plan with strong technical content.This is a comprehensive Quality Engineering Test Plan that demonstrates thorough analysis of the multi-architecture golden images feature. Strengths include:
- Clear requirements and user stories with value propositions
- Well-prioritized test goals (P0/P1)
- Comprehensive test strategy covering functional, monitoring, upgrade, and backward compatibility
- Good requirements-to-test traceability
- Transparent documentation of risks and limitations
The main gaps are process-related (stakeholder agreements, sign-offs, risk resolution) rather than technical content, which should be addressed before finalizing the plan.
292-301: Replace placeholder stakeholder names with actual reviewers and approvers.The sign-off section contains four instances of placeholder text "[Name / @github-username]" under Reviewers and Approvers. Since this Software Test Plan explicitly requires approval from stakeholders, fill in the actual names and GitHub usernames of those responsible for signing off.
237-246: Clarify intent of unchecked status boxes—they appear intentional in this planning document.The unchecked [ ] status in the risks table is typical for design documents tracking future mitigation work. However, there is one inconsistency: Resource Constraints lists the risk as "N/A" with no specific risk identified, yet the status is [ ] instead of [X]. Either mark it [X] to indicate N/A risks are not a concern, or document a specific risk if applicable.
The risk documentation itself is well-structured with clear mitigation strategies and related ticket references. No action needed on the remaining unchecked items—they correctly reflect work pending mitigation as the feature progresses.
Likely an incorrect or invalid review comment.
221-227: Entry criterion appropriately tracked via dependencies.The unchecked criterion "Multi-CPU architecture support enabled in openshift-virtualization repo" is intentionally tracked in the Risks section (line 244) as a documented dependency with a specific action: "Review the PR whenever its ready to review." Since this document is in Draft status, unchecked entry criteria represent planned activities being tracked, not blockers.
Likely an incorrect or invalid review comment.
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Fix all issues with AI agents
In @stps/sig-iuo/golden_image_multiarch_support.md:
- Around line 275-289: The Requirement ID column in the table is empty which
breaks traceability; update each row in the table (the header "Requirement ID"
and the subsequent entries in golden_image_multiarch_support.md) by filling the
leftmost cell with the appropriate Jira issue keys (e.g., CNV-12345 style) that
map to the described requirement/test scenario so every row has a unique
Requirement ID for traceability.
- Line 256: Update the known limitation sentence "Existing VMs not updated: VMs
that are already running will not automatically use new architecture-specific
resources. Users must recreate VMs to take advantage of new resources." to
include the missing verb by changing "Existing VMs not updated:" to "Existing
VMs are not updated:" so the statement reads grammatically correct and retains
the same meaning.
- Line 162: The rationale sentence "If a VM already running, it won't use the
arch-specific resources" is missing the verb "is"; update the text to read "If a
VM is already running, it won't use the arch-specific resources" so the sentence
is grammatically correct (look for that exact phrase in the
golden_image_multiarch_support.md content).
- Line 3: Remove the trailing extra asterisk from the Markdown title string "HCO
support for heterogeneous multi-arch clusters (golden images support) - Quality
Engineering Plan**" so it reads "...Quality Engineering Plan" (without the final
**), ensuring the header is properly formatted.
- Line 55: The Testability table row text is awkward; update the third column
(the cell currently reading "Everything is testable, despite upgrade to a
version which this FG enabled by default.") to a clear, grammatical sentence
such as: "All tests remain valid after upgrading to a version where this feature
gate is enabled by default." Keep the fourth column note ("Should be done in
4.22 timeframe") as-is unless you want to rephrase scheduling language for
consistency.
- Line 25: Update the typo "Muliarch FG" to "MultiArch FG" in the document where
the table entry defines the term for the feature gate; specifically replace the
string "Muliarch FG" with "MultiArch FG" in the row that references the
`enableMultiArchBootImageImport` feature gate so the spelling matches the rest
of the document.
🧹 Nitpick comments (1)
stps/sig-iuo/golden_image_multiarch_support.md (1)
292-301: Complete sign-off section before finalization.The reviewers and approvers sections contain placeholder names. Ensure these are updated with actual names and GitHub usernames before the test plan is finalized and marked as approved.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
stps/sig-iuo/golden_image_multiarch_support.md
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2026-01-08T17:18:15.313Z
Learnt from: yossisegev
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 7
File: stps/sig-network/ip-request-stp.md:0-0
Timestamp: 2026-01-08T17:18:15.313Z
Learning: In the repository RedHatQE/openshift-virtualization-tests-design-docs, the preferred style is "3rd party" without hyphenation, not "third-party".
Applied to files:
stps/sig-iuo/golden_image_multiarch_support.md
🪛 LanguageTool
stps/sig-iuo/golden_image_multiarch_support.md
[style] ~53-~53: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...usters.
2. As a cluster admin, I want to define custom golden images with multi-...
(REP_WANT_TO_VB)
[style] ~278-~278: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... | As a cluster admin, I want to define custom golden images with multi-...
(REP_WANT_TO_VB)
[style] ~279-~279: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... | As a VM creator/cluster admin, I want to create VMs / custom golden images for s...
(REP_WANT_TO_VB)
[style] ~280-~280: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... | As a cluster admin, I want to define custom golden images for specifi...
(REP_WANT_TO_VB)
[style] ~283-~283: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... | As a cluster admin, I want to define custom golden images with multi-...
(REP_WANT_TO_VB)
[style] ~287-~287: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... | As a VM creator/cluster admin, I want to create VMs / custom golden images for s...
(REP_WANT_TO_VB)
[style] ~288-~288: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... | As a VM creator/cluster admin, I want to create VMs / define custom golden image...
(REP_WANT_TO_VB)
🔇 Additional comments (3)
stps/sig-iuo/golden_image_multiarch_support.md (3)
29-35: LGTM! Clear and comprehensive feature overview.The feature overview effectively describes the multi-architecture golden image support, its customer value, and the technical components involved (HCO, SSP, CDI coordination).
160-169: Obtain PM/Lead sign-off for out-of-scope items.The template explicitly states that "All out-of-scope items require explicit stakeholder agreement" and "each out-of-scope item must have PM/Lead sign-off." Currently, all items in the PM/Lead Agreement column are unchecked.
Ensure each out-of-scope item is reviewed and approved by the appropriate stakeholder before finalizing this test plan.
227-227: Complete or document status of entry criterion.The entry criterion "Multi-CPU architecture support enabled in openshift-virtualization repo" is unchecked. Verify whether this is complete or document the blocking status.
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Fix all issues with AI agents
In @stps/sig-iuo/golden_image_multiarch_support.md:
- Around line 275-288: The Requirement ID column in the traceability table is
empty; populate each row with the corresponding Jira issue key so every
requirement traces back to a testable Jira item (follow the doc guidance to use
keys like CNV-12345); either create new Jira issues for each user story/test
scenario or reference parent tickets (e.g., CNV-67900, VIRTSTRAT-494) with
sub-task IDs, and update the table so every row in the Requirement ID column
contains the appropriate Jira key.
- Line 187: The Dependencies table row currently marked "N/A" is inconsistent
with the Risks section which cites a dependency on allowing multi-cpu
architecture in the openshift-virtualization-tests repo (see Risks entry
referencing the PR); update the Dependencies cell for "Dependencies" to
explicitly list the openshift-virtualization-tests change (include the PR
reference or link and the owning team) or, if it truly isn't required, add a
brief justification referencing the Risks line so the table and Risks section
match (edit the table row labeled "Dependencies" to replace "N/A" with the
dependency details or the justification).
- Around line 160-169: The out-of-scope table rows (e.g., entries under the
"Non-Goal" column such as "Testing with s390x architecture", "Templates creation
& utilization", "Imports & datasource new API", etc.) lack stakeholder sign-off
placeholders and therefore remain flagged as risks; contact the responsible
PMs/leads for each listed out-of-scope item, collect their name and sign-off
date, and update each corresponding "[ ] Name/Date" cell with the approver's
name and date (or explicitly document an escalated mitigation note if a sign-off
cannot be obtained) so the table complies with the instructions on lines
referencing stakeholder agreement.
- Line 184: The "Regression Testing" table entry is inconsistent with the NFRs:
update the table row for "Regression Testing" (the cell currently "N/A") to "Y"
and add a brief strategy note referencing the NFR text "Regression: Run IUO T2
tests (must-gather, nodeplacement, golden images tests in particular)" so it
clearly states that IUO T2 tests will be executed as the regression strategy;
alternatively, if regression is intentionally covered elsewhere, replace "N/A"
with a one-line pointer to that section and cite the specific NFR text to avoid
confusion.
🧹 Nitpick comments (1)
stps/sig-iuo/golden_image_multiarch_support.md (1)
296-300: Sign-off placeholders need completion before finalization.The sign-off section contains only placeholder text. While this is expected for a draft document (status "Draft" at line 15), please ensure this section is completed with actual reviewer and approver names before moving to "Final" status.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
stps/sig-iuo/golden_image_multiarch_support.md
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2026-01-08T17:18:15.313Z
Learnt from: yossisegev
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 7
File: stps/sig-network/ip-request-stp.md:0-0
Timestamp: 2026-01-08T17:18:15.313Z
Learning: In the repository RedHatQE/openshift-virtualization-tests-design-docs, the preferred style is "3rd party" without hyphenation, not "third-party".
Applied to files:
stps/sig-iuo/golden_image_multiarch_support.md
🪛 LanguageTool
stps/sig-iuo/golden_image_multiarch_support.md
[style] ~53-~53: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ...usters.
2. As a cluster admin, I want to define custom golden images with multi-...
(REP_WANT_TO_VB)
[style] ~278-~278: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... | As a cluster admin, I want to define custom golden images with multi-...
(REP_WANT_TO_VB)
[style] ~279-~279: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... | As a VM creator/cluster admin, I want to create VMs / custom golden images for s...
(REP_WANT_TO_VB)
[style] ~280-~280: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... | As a cluster admin, I want to define custom golden images for specifi...
(REP_WANT_TO_VB)
[style] ~283-~283: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... | As a cluster admin, I want to define custom golden images with multi-...
(REP_WANT_TO_VB)
[style] ~287-~287: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... | As a VM creator/cluster admin, I want to create VMs / custom golden images for s...
(REP_WANT_TO_VB)
[style] ~288-~288: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... | As a VM creator/cluster admin, I want to create VMs / define custom golden image...
(REP_WANT_TO_VB)
🔇 Additional comments (4)
stps/sig-iuo/golden_image_multiarch_support.md (4)
237-246: Multiple unresolved risks near code freeze.The timeline risk (line 239) indicates "Code-Freeze this week," but the risks table shows most items with status "[ ]" (unresolved), including test environment setup (CNV-73894), dependencies, and a blocker bug (CNV-75762).
Consider updating this section with:
- Current status of each risk item
- Updated mitigation strategies or acceptance that some items will carry into post-GA
- Clear ownership assignments for risk resolution
5-16: Well-structured metadata and clear feature description.The metadata section provides comprehensive tracking information with proper enhancement and Jira references. The feature overview (lines 29-35) clearly explains the coordination between HCO, SSP, and CDI components, and the API extensions table (line 71) documents specific field changes across all affected components.
This level of detail provides excellent context for reviewers and future test maintainers.
Also applies to: 29-35, 71-71
125-145: Testing goals are well-defined and properly prioritized.The functional, monitoring, backward compatibility, and upgrade goals are:
- Specific and measurable
- Properly prioritized (P0 for blocking issues, P1 for important but non-blocking)
- Aligned with the acceptance criteria from Section I (lines 56-56)
- Cover both positive and negative test scenarios
This provides a solid foundation for test implementation.
188-188: Excellent cross-integration scope breakdown.The Cross Integrations row provides clear ownership assignments across IUO, SSP, Storage, and Virt teams with specific testing responsibilities. This clarity is essential for coordinating multi-team features and avoiding coverage gaps.
The explicit callout of monitoring and upgrade testing responsibilities for each component is particularly valuable.
|
/lgtm |
rnetser
left a comment
rnetser
left a comment
There was a problem hiding this comment.
did not complete the review; please address the current comments.
keep in mind that the stp does not include implementation details.
|
|
||
| | Aspect | Predefined (built-in) | Custom (user-defined) | | ||
| |:-------|:----------------------|:----------------------| | ||
| | Annotation source | Set at HCO image build time | User must supply `ssp.kubevirt.io/dict.architectures` | |
There was a problem hiding this comment.
is it ok with PM (i.e that we do not provide this mechanism for customers and that they will need to do it manually)?
rnetser
left a comment
rnetser
left a comment
There was a problem hiding this comment.
High level review as the content needs to be updated with the provided comments before a thourough review can be done
| **Testing Goals** | ||
|
|
||
| New functional flows specific to heterogeneous multi-arch clusters: | ||
|
|
There was a problem hiding this comment.
order the tests under enable.disabled feature - to easily track what is tested when the feature is enabled/diabled
please sort the goals by priority
| - **Acceptance Criteria** | ||
| - *List the acceptance criteria:* | ||
| - VMs must be scheduled only on nodes matching their CPU architecture. | ||
| - VM migration succeeds only between nodes of the same CPU architecture. | ||
| - When multiarch support is enabled, architecture-specific boot sources and templates are available per supported architecture (ARM + AMD) for common golden images. | ||
| - When multiarch support is enabled, architecture-specific boot sources and templates are available ONLY for custom golden images annotated with supported architectures. | ||
| - When multiarch support is enabled, VMs can be created from legacy boot sources, scheduled on node with the default CPU architecture. | ||
| - When multiarch support is enabled, adding a node with a new supported architecture results in architecture-specific boot sources and templates available for this architecture. | ||
| - When multiarch support is enabled, removing all nodes of a supported architecture from a multi-arch cluster cleans up the corresponding architecture-specific boot sources. | ||
| - When multiarch support is disabled and nodePlacement restricts scheduling to a specific supported architecture, VMs are scheduled only on nodes with this CPU architecture. | ||
| - When multiarch support is enabled, new arch images can be pulled successfully only for golden images annotated with supported architectures using any pullMethod. |
There was a problem hiding this comment.
Acceptance criteria should describe observable user outcomes, not internal mechanisms. For example:
- "architecture-specific boot sources and templates are available ONLY for custom golden images annotated with supported architectures" — a user doesn't think in these terms.
Rephrase to: "VMs can be created on ARM64 nodes from available boot sources" or "Custom boot sources ....."
| - **HCO**: | ||
| - `spec.featureGates.enableMultiArchBootImageImport` (bool) - enables/disables golden images support | ||
| - `status.nodeInfo.controlPlaneArchitectures` ([]string) - lists control-plane node architectures | ||
| - `status.nodeInfo.workloadsArchitectures` ([]string) - lists worker node architectures | ||
| - `status.dataImportCronTemplates[].status.originalSupportedArchitectures` (string) - preserves original annotation values | ||
| - `status.dataImportCronTemplates[].status.conditions` - deployment conditions including `UnsupportedArchitectures` reason | ||
| - **SSP**: | ||
| - `spec.enableMultipleArchitectures` (bool) - feature activation flag | ||
| - `spec.cluster.workloadArchitectures` ([]string) - worker arch list from HCO | ||
| - `spec.cluster.controlPlaneArchitectures` ([]string) - control-plane arch list from HCO | ||
| - **CDI**: | ||
| - `DataVolumeSourceRegistry.platform.architecture` (string) - specifies target CPU architecture for import | ||
| - `DataSourceSource.dataSource.namespace` (string) - Pointer DataSource namespace | ||
| - `DataSourceSource.dataSource.name` (string) - Pointer DataSource name | ||
| - **KubeVirt**: | ||
| - `vm.spec.template.spec.architecture` (string) - targets VM to specific CPU architecture |
There was a problem hiding this comment.
This lists 12+ internal API fields across HCO, SSP, CDI, KubeVirt. The STP should only mention user-facing APIs. Keep only:
- vm.spec.template.spec.architecture — new field on VM spec
- Multi-arch support configured through HCO
| - *Rationale:* Not in scope per VIRTSTRAT-494. | ||
| - *PM/Lead Agreement:* [Name/Date] | ||
|
|
||
| **Test Limitations** |
There was a problem hiding this comment.
please make sure to get PM sign off before merge
| 1. [[UI] architecture is incorrect for fedora arm and inconsistent on UI for other os](https://issues.redhat.com/browse/CNV-68981) | ||
| 2. [[Storage] Arch-specific DataSources (arm64) persist after removing arm64 nodes](https://issues.redhat.com/browse/CNV-68996) |
There was a problem hiding this comment.
please fix ref to cloud jira
Signed-off-by: Harel Meir <hmeir@redhat.com>
Signed-off-by: Harel Meir <hmeir@redhat.com>
Signed-off-by: Harel Meir <hmeir@redhat.com>
Signed-off-by: Harel Meir <hmeir@redhat.com>
Signed-off-by: Harel Meir <hmeir@redhat.com>
…mation Signed-off-by: Harel Meir <hmeir@redhat.com>
Signed-off-by: Harel Meir <hmeir@redhat.com>
Signed-off-by: Harel Meir <hmeir@redhat.com>
Signed-off-by: Harel Meir <hmeir@redhat.com> Made-with: Cursor
Signed-off-by: Harel Meir <hmeir@redhat.com>
Signed-off-by: Harel Meir <hmeir@redhat.com>
Signed-off-by: Harel Meir <hmeir@redhat.com>
Signed-off-by: Harel Meir <hmeir@redhat.com>
| - **[P0]** Verify cross-architecture migration is blocked with a clear, user-facing error message. | ||
| - **[P0]** Verify cross-architecture VM cloning is blocked with a clear, user-facing error message. | ||
| - **[P0]** Verify network connectivity between VMs running on different architectures. | ||
| - **[P0]** Verify golden image import pulls the correct architecture-specific image. |
There was a problem hiding this comment.
| **Test Coverage** | ||
|
|
||
| - **Risk:** OS coverage on ARM64 is narrower than AMD64; sig-network and sig-storage teams must identify ARM-relevant tests and mark them for heterogeneous cluster execution. | ||
| - **Mitigation:** sig-storage, sig-network teams must detect ARM-related D/S tests and mark them accordingly. |
There was a problem hiding this comment.
please let these teams explain how they are going to mitigate this risk
| - **[CNV-67900](https://redhat.atlassian.net/browse/CNV-67900)** — As a cluster Admin, I want to create VM with specific architecture. | ||
| - *Test Scenario:* [Tier 2] Given multi-arch support enabled, Verify common architecture-specific boot sources become available with correct naming and labels | ||
| - *Priority:* P0 |
There was a problem hiding this comment.
this flow is repeated - we want to verify that we can run VMs from all available boot sources - i think that one team can own this.
to unblock this stp, you can leave it but makes ure that the teams are aligned and no duplicate work is done
|
|
||
| The following items are explicitly Out of Scope for this test cycle and represent intentional exclusions. | ||
| No verification activities will be performed for these items, and any related issues found will not be classified as defects for this release. | ||
|
|
There was a problem hiding this comment.
signoff is missing - once you get PM ack , please add here with ref to the ack
| - *Rationale:* Not in scope per VIRTSTRAT-494. | ||
| - *PM/Lead Agreement:* [Name/Date] | ||
|
|
||
| **Test Limitations** |
| The limitations are documented to ensure alignment between development, QA, and product teams. | ||
| The following are confirmed product constraints accepted before testing begins. | ||
|
|
||
| - Cross-architecture live migration is not supported (AMD64 <-> ARM64). |
13 participants
STP Metadata
VEP issue:https://github.com/kubevirt/enhancements/blob/main/veps/sig-storage/dic-on-heterogeneous-cluster/dic-on-heterogeneous-cluster.md
What this PR does
Multiarch golden image support HCO
Special notes for your reviewer
Summary by CodeRabbit