update dual stream stp for cnv-5.0 - #142
Conversation
📝 WalkthroughWalkthroughThe STP replaces fixed RHCOS 9.8/10.2 references with RHCOS9.x/RHCOS10.x terminology. It updates CNV coverage, topology, provisioning, automation, FIPS testing, risks, and bidirectional live-migration scenarios. ChangesDual-stream STP
Estimated code review effort: 2 (Simple) | ~15 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Report bugs in Issues Welcome! 🎉This pull request will be automatically processed with the following features: 🔄 Automatic Actions
📋 Available CommandsPR Status Management
Review & Approval
Testing & Validation
Cherry-pick Operations
Branch Management
Label Management
✅ Merge RequirementsThis PR will be automatically approved when the following conditions are met:
📊 Review ProcessApprovers and ReviewersApprovers:
Reviewers:
Available Labels
AI Features
Security Checks
💡 Tips
For more information, please refer to the project documentation or contact the maintainers. |
|
mtessun can not be added as reviewer. Reviews may only be requested from collaborators. One or more of the users or teams you specified is not a collaborator of the RedHatQE/openshift-virtualization-tests-design-docs repository.: 422 {"message": "Reviews may only be requested from collaborators. One or more of the users or teams you specified is not a collaborator of the RedHatQE/openshift-virtualization-tests-design-docs repository.", "documentation_url": "https://docs.github.com/rest/pulls/review-requests#request-reviewers-for-a-pull-request", "status": "422"} |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md`:
- Line 315: Update the risk entry in the Dual-Stream cluster documentation to
identify the specific affected cloud platforms and FIPS-related failure mode,
then state the supported mitigation or fallback. Clarify whether bare-metal
deployment is required or whether cloud testing remains supported when FIPS is
available.
- Around line 180-185: Remove the hard-coded “el9.8 userspace” qualifier from
the OCPSTRAT-1150 scope statement in stp.md. Keep the requirement generalized to
the full supported RHCOS9.x coverage and preserve the existing dual-stream
live-migration scenarios.
- Around line 27-35: Generalize the RHCOS9.x and RHCOS10.x definitions in the
terminology section instead of tying them to specific minor releases, while
preserving their OCP and support-status context. Update the Feature Overview to
explicitly identify the current maturity phase and state which phase this STP
covers, using consistent generalized terminology throughout the document.
- Around line 220-222: Remove the hidden Upgrade Testing TODO HTML comment from
Section II.2 and add a visible Upgrade Testing checklist entry. Mark it [ ] with
an explicit out-of-scope rationale, or [x] only if the testing is in scope and
complete, while preserving the requirement that all 13 test-strategy categories
are visibly listed.
- Around line 63-72: Update the Acceptance Criteria section to replace broad,
unbounded phrases such as “All CNV features” and “identically” with an
explicitly supported CNV feature scope, or delegate feature coverage to named
child STPs. Define measurable, user-observable outcomes for dual-stream
behavior, live migration, and component readiness, and ensure each criterion
maps directly to a testable scenario.
- Around line 176-179: Correct the test-strategy regression lists near the
affected entries, including the sections around the CNV validation text and the
referenced additional ranges: remove the malformed nested dash, standardize
every “Tier1” occurrence to “Tier 1” and “adhoc” to “ad hoc,” and keep the
resulting bullets concise, grammatical, and consistently structured.
- Around line 356-367: Update Section III to provide traceability for every
P0/P1 Testing Goal and Acceptance Criterion covering RHCOS10.x-only workloads,
dual-stream clusters, and CNV readiness. Add Jira-backed test scenarios with
requirement IDs, tiers, and priorities, or explicitly link each item to its
owning child STP; retain the existing CNV-81251 migration scenarios.
- Around line 215-218: Align the compatibility claim in the Compatibility
Testing section with the available test coverage: either expand the environment
matrix beyond OCP/CNV 5.0 to cover every supported version from 4.22 through
5.2, or add CI/child-STP coverage that exercises that full range before
retaining the claim.
- Around line 187-191: Update the dual-stream references across sections II.2,
CI/CD, Entry Criteria, and Risks to consistently describe the phase-specific
OCPSTRAT-1150 automation status: manual ad-hoc testing for the 4.22 Tech Preview
and node-affinity-based Tier 2 automation by 5.0 GA. Align provisioning and
entry criteria with the required test coverage, and remove contradictory
statements that automation is already required or still being implemented
without risk.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 07c1f2ff-6306-4c44-818d-8c2b4ea3d928
📒 Files selected for processing (1)
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md (1)
79-80: 🔒 Security & Privacy | 🟠 Major | ⚡ Quick winHIGH — Align security requirements with the test strategy.
Section I.1 requires FIPS-enabled testing, while Section II.2 marks Security Testing as N/A. Additionally, Performance, Scale, Usability, and Monitoring are marked
[x]despite being N/A; per the checklist convention, non-applicable items must be[ ]with justification. Keep Security checked and define its FIPS validation, or revise the NFR.Also applies to: 204-212
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md` around lines 79 - 80, Align the NFR checklist with the stated test strategy: keep Security Testing selected and document FIPS-enabled validation consistent with Section I.1, or revise the FIPS requirement if security testing is truly not applicable. In the affected checklist entries, change Performance, Scale, Usability, and Monitoring from “[x]” to “[ ]” and retain clear N/A justifications.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md`:
- Line 82: Add the required PM/UX customer-value justification to the UI testing
statement in the feature documentation, explaining why UI testing provides no
value for this change; alternatively, mark UI testing as applicable if that
rationale cannot be supported.
- Line 81: Update the Scalability NFR in the dual-stream cluster scenario to
specify the supported cluster-level live migration parallelism limit, link to
the authoritative documentation or configuration, and describe the validation
test that confirms migrations remain within that boundary.
---
Outside diff comments:
In `@stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md`:
- Around line 79-80: Align the NFR checklist with the stated test strategy: keep
Security Testing selected and document FIPS-enabled validation consistent with
Section I.1, or revise the FIPS requirement if security testing is truly not
applicable. In the affected checklist entries, change Performance, Scale,
Usability, and Monitoring from “[x]” to “[ ]” and retain clear N/A
justifications.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 496e2bb6-aeba-433c-93cd-0bc6a1347ef8
📒 Files selected for processing (1)
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
openshift-virtualization-qe-bot-5
removed
the
changes-requested-coderabbitai[bot]
label
|
mtessun can not be added as reviewer. Reviews may only be requested from collaborators. One or more of the users or teams you specified is not a collaborator of the RedHatQE/openshift-virtualization-tests-design-docs repository.: 422 {"message": "Reviews may only be requested from collaborators. One or more of the users or teams you specified is not a collaborator of the RedHatQE/openshift-virtualization-tests-design-docs repository.", "documentation_url": "https://docs.github.com/rest/pulls/review-requests#request-reviewers-for-a-pull-request", "status": "422"} |
|
Clean rebase detected — no code changes compared to previous head ( |
|
mtessun can not be added as reviewer. Reviews may only be requested from collaborators. One or more of the users or teams you specified is not a collaborator of the RedHatQE/openshift-virtualization-tests-design-docs repository.: 422 {"message": "Reviews may only be requested from collaborators. One or more of the users or teams you specified is not a collaborator of the RedHatQE/openshift-virtualization-tests-design-docs repository.", "documentation_url": "https://docs.github.com/rest/pulls/review-requests#request-reviewers-for-a-pull-request", "status": "422"} |
Signed-off-by: akri3i <guptaakriti70@gmail.com>
|
mtessun can not be added as reviewer. Reviews may only be requested from collaborators. One or more of the users or teams you specified is not a collaborator of the RedHatQE/openshift-virtualization-tests-design-docs repository.: 422 {"message": "Reviews may only be requested from collaborators. One or more of the users or teams you specified is not a collaborator of the RedHatQE/openshift-virtualization-tests-design-docs repository.", "documentation_url": "https://docs.github.com/rest/pulls/review-requests#request-reviewers-for-a-pull-request", "status": "422"} |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md`:
- Around line 221-222: Update the Upgrade Testing checklist item in the STP
document from [x] to [ ] because it is explicitly out of scope, while preserving
its existing details and wording.
- Around line 315-319: Resolve the contradiction between required Cloud Testing
and the FIPS cloud-platform limitation in the risk and environment sections of
stp.md. Until OCPBUGS-64660 is fixed, explicitly mark cloud testing as optional
or out of scope and retain bare metal as the supported FIPS test environment, or
define a supported FIPS-enabled cloud environment with clear execution criteria.
- Around line 97-101: Align the dual-stream cluster provisioning status across
the STP: update the “DevOps QE to provide this capability” statement to match
the later sections’ documented status, or consistently identify the tooling as
pending if it remains unstable. Ensure all related entry criteria and
dependencies accurately distinguish completed versus outstanding work.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 7c34ba93-792b-48a5-9995-545740598701
📒 Files selected for processing (1)
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
RedHatQE/openshift-virtualization-tests(manual)
📜 Review details
🧰 Additional context used
📓 Path-based instructions (4)
**/stps/**/stp.md
📄 CodeRabbit inference engine (CLAUDE.md)
Use stps/stp-template/stp.md as the template for STP documents with inline instructions
Files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
**/*.md
📄 CodeRabbit inference engine (CLAUDE.md)
Adhere to markdown linting configuration defined in .markdownlint.yaml
Follow Markdown formatting standards: specify languages for code blocks, provide image alt text, avoid consecutive blank lines and trailing whitespace, and end files with a newline.
Files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
stps/**/*.md
📄 CodeRabbit inference engine (AGENTS.md)
stps/**/*.md: Ensure every claim has evidence, including actual sign-offs, Jira links, and dates; do not leave placeholders in approved STPs.
Keep Feature Limitations, Test Limitations, Out of Scope, and Risks distinct; document each category using its required rationale, constraints, mitigation, or sign-off fields.
Every test scenario must trace to a real Jira requirement ID and include a tier and priority; every testing goal and acceptance criterion must have corresponding traceability.
Feature metadata must include justified enhancement, feature, and epic links; maturity phases and versions in the required DP/TP/GA format; QE ownership; correct SIGs; and consistent VEP/design-document references.
Feature Overview sections must be 2–8 sentences, explain customer value, use user-facing language, omit implementation details, and identify the covered maturity phase when applicable.
Requirements must be specific and testable; use user-story format for use cases and requirement summaries, and make acceptance criteria individual observable pass/fail conditions.
For seamless or non-disruptive features, include an acceptance criterion that would fail after a disrupt-then-restore sequence rather than checking only the final state.
Address all required NFR categories—Monitoring, Observability, UI, Documentation, Performance, Security, and Scalability—with justification for categories that do not apply; acknowledge limits of underlying platform mechanisms.
Testing goals must be user-facing, SMART, prioritized P0/P1/P2, actionable across all required configuration dimensions, and distinguish new functional tests from regression tests.
Consider negative, edge-case, concurrent, failure, and error-handling scenarios; justify tests that only assess behavior after the system reaches a stable state.
Test Strategy must address all 14 template testing types, justify unchecked or N/A items, evaluate upgrade paths, document monitoring requirements, and identify ownership for UI testi...
Files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
stps/**
⚙️ CodeRabbit configuration file
stps/**: ## Test implementation cross-reference (STP → tests)Skip this check entirely for files under
stps/stp-template/— those are
templates, not feature STPs.When a feature STP file under
stps/is modified, determine whether the change
is meaningful (affects test implementation) or cosmetic (no test impact).Meaningful changes (flag for test update):
- Test scenarios added, removed, or modified in Section III (table rows changed)
- Testing goals added, removed, or reprioritized in Section II.1
- Requirements added, removed, or modified in Section I.1
- Acceptance criteria added, removed, or changed in Section I.1
- Tier or priority changes on existing scenarios
- Scope changes in Section II.1 (Out of Scope items added or removed)
- Test Limitations changes in Section II.1 that alter what QE can validate
- Test strategy changes in Section II.2 that affect what is tested
- Test environment changes in Section II.3 that affect how tests run
Cosmetic changes (skip cross-ref check):
- Typo fixes, grammar corrections, punctuation changes
- Formatting or whitespace adjustments
- Rewording that preserves the same test intent and pass/fail criteria
- Sign-off updates, reviewer list changes
- Metadata-only changes (dates, version bumps, document conventions)
- Risk section updates that do not change test scope
When meaningful changes are detected:
First, use the linked repository (
RedHatQE/openshift-virtualization-tests) to check
whether existing tests reference this STP viaSTP:orSTP Reference:URLs
in docstrings (both conventions are used in the tests repo).If no tests reference this STP (greenfield STP with no test coverage yet),
skip the cross-reference notice entirely. The tests repo enforces STP-to-test
alignment when tests land.If tests reference this STP, post a non-blocking MEDIUM severity advisory listing:
- Which sections changed meaningfully (scenarios, goals, criteria, scope)
- A summary of what changed (e...
Files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
🧠 Learnings (24)
📚 Learning: 2026-01-26T12:49:09.313Z
Learnt from: azhivovk
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 15
File: stps/sig-network/ipv6-single-stack-stp.md:169-175
Timestamp: 2026-01-26T12:49:09.313Z
Learning: In documentation files under stps/, when documenting test scenarios in the 'Test Scenarios & Traceability' table, it's acceptable to reuse a single epic ID (e.g., CNV-28924) for all requirement rows that fall under that epic instead of creating unique sub-requirement IDs for each scenario. This applies only to this repository's documentation guidelines; confirm with project governance if this affects traceability or tooling used for test execution mapping.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-04-13T10:27:58.826Z
Learnt from: azhivovk
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 65
File: stps/sig-virt/heterogeneous-rhcos9-rhcos10/network.md:187-187
Timestamp: 2026-04-13T10:27:58.826Z
Learning: When reviewing STP markdown docs in this repo (e.g., under `stps/`), do not flag the template default in Section II.3.1 “Testing Tools & Frameworks” where `- **Test Framework:** Standard` is used. This is intentional and indicates no new or non-standard tools are required. Only suggest changes if the feature introduces a new/modified test framework, a custom test harness, or significant test infrastructure changes beyond the standard baseline.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-05-08T14:46:58.959Z
Learnt from: kshvaika
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 86
File: stps/sig-storage/scratch_space_sc_selection_logic.md:406-423
Timestamp: 2026-05-08T14:46:58.959Z
Learning: In this repository’s STP documents (under `stps/`), in Section III (“Test Scenarios & Traceability”), it may be intentional for scenarios to be labeled `[Tier 2]` even when the scenario represents a single CDI operation (e.g., import, upload, clone) if the corresponding `[Tier 1]` tests already exist and are maintained/updated by the developer elsewhere. During review, do not treat `[Tier 2]` labels as incorrect unless you first confirm whether the matching Tier 1 coverage is already present externally.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-05-08T14:48:53.503Z
Learnt from: kshvaika
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 86
File: stps/sig-storage/scratch_space_sc_selection_logic.md:402-425
Timestamp: 2026-05-08T14:48:53.503Z
Learning: When reviewing STP design docs under stps/..., treat Section III test scenarios labeled "[Tier 2]" as potentially intentional even if they cover only a single CDI operation (e.g., import, upload, clone), as long as matching "[Tier 1]" tests exist and are maintained/updated outside the STP by the developer. Do not automatically flag "[Tier 2]" for single-operation scenarios until you confirm whether corresponding "[Tier 1]" coverage is already provided externally elsewhere in the repo/project.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-05-11T12:14:47.209Z
Learnt from: akri3i
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 92
File: stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md:0-0
Timestamp: 2026-05-11T12:14:47.209Z
Learning: In this repository’s STP documentation files under `stps/`, acceptance criteria for “non-disruptive” behaviors (for example, live migration) should be written at a high level. Describe WHAT must be verified (e.g., “no disruption during migration”, “continuous connectivity validated”) but avoid prescribing HOW to measure it (e.g., specific ICMP ping intervals, TCP RST/FIN tracking, exact packet-loss thresholds). Low-level verification methodology belongs in the associated test cases or test scripts, not in the STP. Do not treat an STP acceptance criterion as insufficient solely because it does not include low-level verification mechanics.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-05-25T07:16:20.059Z
Learnt from: josemacassan
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 78
File: stps/sig-storage/storage_mig_cleanup.md:66-70
Timestamp: 2026-05-25T07:16:20.059Z
Learning: When reviewing STP design docs in this repo (e.g., under stps/), if a feature’s operation (such as post-migration cleanup) purely delegates to an existing controller and does not introduce any new scalability surface—specifically no new concurrency paths/worker model, no new rate-limiting behavior, no increased/decreased CRD cardinality, and no new CRD types or new API call patterns—then it is intentional to set the NFR field "Scalability" to "Not applicable - cleanup scales with existing [controller] capabilities." In that case, do not flag the NFR justification as being too generic. If the feature genuinely adds scalability impact, require a proper scalability assessment instead of using the Not applicable rationale.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-05-25T09:46:33.392Z
Learnt from: kshvaika
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 106
File: stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/storage.md:64-71
Timestamp: 2026-05-25T09:46:33.392Z
Learning: In this repository’s STP docs under `stps/`, when reviewing a *child STP* (category/domain-scoped doc) such as `storage.md`, `network.md`, etc. that lives in a feature directory alongside a parent `stp.md`, do not require the full per-category NFR justification (Monitoring, Observability, UI, Documentation, Performance, Security, Scalability with PM/UX backing and explicit scalability constraints). For child STPs, it’s sufficient to confirm that **no new NFRs are introduced in this scope** and include brief per-category bullets; the complete NFR treatment for the feature is owned by the parent `stp.md`.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-05-25T09:54:44.096Z
Learnt from: kshvaika
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 106
File: stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/storage.md:139-142
Timestamp: 2026-05-25T09:54:44.096Z
Learning: In STP documents under `stps/`, for Section II.1 “Test Limitations” and similarly named placeholder/known-limitation sections (e.g., “Known Limitations” / “None”), do not require a sign-off line of the form `*Sign-off:* [Name/Date]` when the section is only a bare “None” statement. Require an explicit sign-off only when actual limitations/test constraints are listed that need reviewer acknowledgment; if limitations are present but the sign-off is missing, it should be flagged.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-05-25T09:57:32.773Z
Learnt from: kshvaika
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 106
File: stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/storage.md:153-190
Timestamp: 2026-05-25T09:57:32.773Z
Learning: When reviewing STP documents under `stps/`, follow the Test Strategy checklist convention in Section II.2: use `[x]` only when the checklist item is applicable and has been addressed, and use `[ ]` when the item is NOT applicable. For `[ ]` items, require a clear justification in the corresponding `Details:` field. Do not treat `[ ]` as an incorrect omission solely because the `Details:` field contains text—such text is the required non-applicability explanation, not evidence that the item was completed.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-05-27T18:26:25.780Z
Learnt from: RoniKishner
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 34
File: stps/sig-infra/virtual-machine-template.md:64-69
Timestamp: 2026-05-27T18:26:25.780Z
Learning: When reviewing STP documents in the `stps/` directory, do not require NFR categories like Monitoring, Performance, and Scalability to be re-enumerated in the Section I.1 “Non-Functional Requirements (NFRs)” block if they are already explicitly addressed (with justification) elsewhere in the same STP—specifically in a dedicated “Out of Scope” section. In this case, treating duplication as redundant is acceptable. Also, Observability may be treated as a subset of Monitoring rather than a separate NFR category. Do not flag the I.1 NFR block as incomplete solely because these categories are missing from it when they are covered elsewhere in the document.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-05-27T18:36:25.091Z
Learnt from: RoniKishner
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 34
File: stps/sig-infra/virtual-machine-template.md:10-13
Timestamp: 2026-05-27T18:36:25.091Z
Learning: In STP design documents located under `stps/`, Feature Maturity block entries are allowed to include optional trailing descriptive text after the version label. For example, lines like `DP: 4.21 - Deployed by manual installation` are valid. Consider the structured format satisfied as long as each bullet starts with the correct phase label and version value (e.g., `DP: [version|N/A]`, `TP: [version|N/A]`, `GA: [version]`). Do not flag a violation solely because there is additional descriptive text after the version number.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-06-02T10:06:00.601Z
Learnt from: rnetser
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 34
File: stps/sig-infra/virtual-machine-template.md:133-168
Timestamp: 2026-06-02T10:06:00.601Z
Learning: When reviewing any STP document under `stps/`, check Section II.2 (“Test Strategy”). It must explicitly enumerate every testing type required by the STP template. No testing type may be omitted: if a testing type is not applicable, it still must be listed and accompanied by a clear justification/rationale. Do not treat Section II.2 as complete if any required testing types are missing—missing entries indicate the template’s testing types were not documented as considered (a review violation).
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-07-07T08:33:28.371Z
Learnt from: OhadRevah
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 108
File: stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/iuo.md:40-40
Timestamp: 2026-07-07T08:33:28.371Z
Learning: In STP documentation under the stps/ directory, do not flag the term “must-gather” as an internal implementation detail. “must-gather” is an official, customer/support-facing OpenShift tool name (from `oc adm must-gather`). Use the official name to improve precision/traceability for QE and support; this is consistent with STP guidance to describe user experience rather than internal mechanisms.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-07-16T00:58:10.501Z
Learnt from: geetikakay
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 128
File: stps/sig-infra/CNV-82132-pause-guest-agent-probes.md:142-143
Timestamp: 2026-07-16T00:58:10.501Z
Learning: Until the STP review process changes (moving PM-review-scoped items into a PR template with checkboxes) are finalized and documented, continue requiring inline PM/UX justification inside STP documents. In particular, if you mark items as out of scope or skip Usability Testing (and similar PM/UX-scoped exceptions), include the required inline justification in the STP text rather than relying on the PR template/checkbox mechanism.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-07-16T01:22:56.191Z
Learnt from: geetikakay
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 128
File: stps/sig-infra/CNV-82132-pause-guest-agent-probes.md:5-18
Timestamp: 2026-07-16T01:22:56.191Z
Learning: For STP design docs in the `stps/` directory, ensure the Feature Maturity/phase metadata follows the required DP/TP/GA structured block (e.g., `DP: <version or N/A>`, `TP: <version or N/A>`, `GA: <version>`). Do not rely on an Epic Tracking Jira link title that merely includes a phase label (e.g., `GA: Implement ...`) as a substitute. Also ensure the Feature Overview explicitly states which phase the STP covers.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-07-16T01:23:24.642Z
Learnt from: geetikakay
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 128
File: stps/sig-infra/CNV-82132-pause-guest-agent-probes.md:101-113
Timestamp: 2026-07-16T01:23:24.642Z
Learning: For STP documentation under stps/ (e.g., *.md files), keep Section II.1 “Testing Goals” as high-level, priority-ordered “what we’re trying to achieve” statements (e.g., P0/P1/P2). Do not require Section II.1 to enumerate every configuration dimension (such as VMI state, probe configuration, annotation values, guest-agent state, migration topology, or detailed observable/expected outcomes). Instead, verify that all such detailed dimensions are covered via traceability in Section III (“Test Scenarios & Traceability”), where each scenario maps to the corresponding Jira Requirement ID, Tier, and Priority.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-07-20T13:19:16.186Z
Learnt from: geetikakay
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 128
File: stps/sig-infra/CNV-82132-pause-guest-agent-probes.md:269-274
Timestamp: 2026-07-20T13:19:16.186Z
Learning: When reviewing STP design documentation under stps/ (e.g., STP markdown files), note that any traceability additions flagged during the review may be generated by the STP writer after the STP review. Do not require those post-review traceability edits to be present at review time, but you must verify that the final generated STP submitted for approval still includes the required Section III test scenarios.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-07-29T22:30:28.619Z
Learnt from: SamAlber
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 138
File: stps/sig-virt/pci-topology-stability.md:7-10
Timestamp: 2026-07-29T22:30:28.619Z
Learning: When authoring an STP doc under the `stps/` directory that is explicitly regression-only (i.e., the plan does not introduce or cover any new feature), do not include/claim feature maturity details or epic tracking. Instead, use the corresponding regression-test Jira issue(s) (e.g., `CNV-81270`) as the primary traceability reference for the plan.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-08-02T17:42:04.538Z
Learnt from: SamAlber
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 138
File: stps/sig-virt/pci-topology-stability.md:154-158
Timestamp: 2026-08-02T17:42:04.538Z
Learning: In STP documents under stps/**/*.md, Section II.3.1 should document only new or non-standard tooling and special CI/CD jobs or lanes. If a test runs in an existing standard Tier 2 CI lane or the standard upgrade CI lane, treat `CI/CD: N/A` as correct; do not require those standard lanes to be listed merely because the STP identifies where automated tests run.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-08-04T10:39:51.886Z
Learnt from: akri3i
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 142
File: stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md:82-82
Timestamp: 2026-08-04T10:39:51.886Z
Learning: In STP NFR sections, a UI testing category may be marked N/A without separate PM agreement only when the document explicitly states that the feature introduces no UI changes and that UI testing would provide no customer value. Treat these statements as the required justification for the non-applicable NFR category.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-04-13T10:20:13.766Z
Learnt from: azhivovk
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 65
File: stps/sig-virt/heterogeneous-rhcos9-rhcos10/network.md:174-174
Timestamp: 2026-04-13T10:20:13.766Z
Learning: In this repository’s design-doc markdown files under stps/sig-virt/**, if a feature’s tests are truly storage-agnostic (i.e., the test outcomes are unaffected by the storage type, such as network-focused STPs), then in Section II.3 “Test Environment” use an explicit StorageClass statement like “Any available StorageClass (network-focused tests; storage type does not affect test outcomes)” rather than the bare word “Agnostic”. Also ensure Section II.3 “Platform” is always explicitly populated (e.g., “Bare metal”), not left unspecified.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-06-11T09:44:33.004Z
Learnt from: OhadRevah
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 108
File: stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/iuo.md:230-233
Timestamp: 2026-06-11T09:44:33.004Z
Learning: For child STP markdown documents under `stps/sig-virt/<feature-name>/` (e.g., `network.md`, `storage.md`, `iuo.md`), in Section II.5 “Risks” do not require all 6 standard risk categories (Timeline/Schedule, Test Coverage, Test Environment, Untestable Aspects, Resource Constraints, Dependencies). Per the child STP template, include only the categories that have SIG-specific risk; omit categories with no SIG-specific risk and do not flag missing categories. In contrast, parent `stp.md` files must enumerate all 6 categories with full entries or explicit justification.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-06-08T14:06:59.507Z
Learnt from: RoniKishner
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 34
File: stps/sig-infra/virtual-machine-template.md:187-187
Timestamp: 2026-06-08T14:06:59.507Z
Learning: In STP documents under stps/sig-*/ (including stps/sig-infra/), when a feature has no platform-specific behavior and applies equally to all CI platforms, document the Section II.3 "Platform" field as "Platform-agnostic — no platform-specific behavior; applicable to all CI platforms." or "N/A" instead of enumerating a fixed platform list. Do not require an explicit platform list in this scenario to avoid maintenance overhead when new CI platforms are added.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
📚 Learning: 2026-07-23T10:59:09.830Z
Learnt from: akri3i
Repo: RedHatQE/openshift-virtualization-tests-design-docs PR: 142
File: stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md:63-72
Timestamp: 2026-07-23T10:59:09.830Z
Learning: For STP documentation files named `stp.md` under the `stps/` hierarchy, if the STP is a parent STP, keep its content high-level. Delegate SIG-specific, feature-specific test scenario definitions to the appropriate child STPs owned by the participating SIGs, and avoid duplicating scenario lists or detailed coverage descriptions that belong in those child STPs.
Applied to files:
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
🪛 LanguageTool
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md
[style] ~60-~60: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... nodes. - As a platform team, I want to validate that CNV behaves correctly on ...
(REP_WANT_TO_VB)
[grammar] ~179-~179: Ensure spelling is correct
Context: ...e primary mechanism is running existing Tier1, Tier 2 and Tier 3 test suites and tria...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~181-~181: Ensure spelling is correct
Context: ...iuo, sig-infra) must document their Tier1, Tier 2 and Tier 3 Test results and bug...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~184-~184: Ensure spelling is correct
Context: ...m RHCOS9.x to RHCOS10.x worker node and backto RHCOS9.x i.e VM created first...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~186-~186: Ensure spelling is correct
Context: ...m RHCOS10.x to RHCOS9.x worker node and backto RHCOS10.x i.e VM created firs...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[uncategorized] ~318-~318: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...S-64660). - Mitigation: - Use bare metal cluster with FIPS enabled (primary test...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
🔀 Multi-repo context RedHatQE/openshift-virtualization-tests
Linked repositories findings
RedHatQE/openshift-virtualization-tests
pytest.ini:77defines themixed_os_nodesmarker as requiring both RHCOS 9 and RHCOS 10 worker nodes, matching the STP’s generalized RHCOS9.x/RHCOS10.x scope.[::RedHatQE/openshift-virtualization-tests::]tests/virt/cluster/migration_and_maintenance/rhel9_rhel10_cluster/test_live_migration.py:59-143contains automated bidirectional live-migration coverage for RHCOS 9↔10, including RHEL and Windows VMs and Polarion cases CNV-16274/CNV-16275. This supports the STP’s statement that migration testing is automated by the component team.[::RedHatQE/openshift-virtualization-tests::]- Network migration coverage similarly exists for primary networking and Linux bridge connectivity at
tests/network/primary_network/rhel9_rhel10_cluster/test_connectivity.py:31-88andtests/network/l2_bridge/rhel9_rhel10_cluster/test_connectivity.py:36-105, with both migration directions covered.[::RedHatQE/openshift-virtualization-tests::] - The executable tests link directly to the design-doc STP, but no references to the specific RHCOS 9.8/10.2 versions, CNV-84749, CNV-81251, or OCPBUGS-64660 were found in this repository.
[::RedHatQE/openshift-virtualization-tests::]
🔇 Additional comments (5)
stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md (5)
31-35: HIGH — State the covered maturity phase in Feature Overview.The metadata declares TP
v4.22and GAv5.0, but Feature Overview only states that support starts with OCP 4.22. Add a sentence that this parent STP covers RHCOS 10.x GA in CNV 5.0.As per coding guidelines, Feature Overview sections must identify the covered maturity phase.
Source: Coding guidelines
177-187: LOW — The previously reported test-strategy wording remains.
Tier1,backto, andi.eremain in the migration steps. UseTier 1,back to, andi.e.,consistently in both directions.As per coding guidelines, test-strategy lists must be concise, actionable, and grammatically clear.
Sources: Coding guidelines, Linters/SAST tools
216-237: 📐 Maintainability & Code QualityMEDIUM — Verify the full 14-item Test Strategy checklist.
The visible checklist names 13 testing items. Compare Section II.2 with
stps/stp-template/stp.md. Add the missing template type, or list it as[ ]with a clear N/A rationale.As per coding guidelines, Test Strategy must address all 14 template testing types and justify non-applicable items.
Source: Coding guidelines
228-231: 🗄️ Data Integrity & IntegrationHIGH — Verify parent-to-child STP links.
This section instructs
sig-network,sig-storage,sig-iuo, andsig-infrato create child STPs, but the provided parent content does not show links to those documents. Confirm that each child exists, the parent links each child, and each child links back. Add the missing links if necessary.As per coding guidelines, the required multi-SIG structure includes parent-to-child and child-to-parent references.
Source: Coding guidelines
352-364: 🗄️ Data Integrity & IntegrationMEDIUM advisory — Verify linked test implementation after changing these scenarios.
Section III meaningfully changed both
CNV-81251scenarios from fixed RHCOS 9.8/10.2 versions to generalized RHCOS9.x/RHCOS10.x scope.The linked
RedHatQE/openshift-virtualization-testsrepository already references this STP and contains bidirectional RHCOS 9↔10 migration coverage. Verify that the test docstrings,STP:links, and Polarion mappings use the generalized scenario scope.
⚠️ Test implementation may need updating.
The following sections changed meaningfully:
- Requirements and acceptance criteria
- Testing goals and limitations
- Test strategy and automation
- Test environment and CI/CD
- Two Section III migration scenarios
Please verify that linked test coverage reflects these changes. This advisory should not block approval of the STP.
As per path instructions, meaningful STP changes require a linked-test cross-reference when existing tests reference the STP.
Sources: Path instructions, Linked repositories
| - **CNV compatibility on RHCOS 10.x:** RHCOS 10.x is a new platform configuration that may | ||
| surface unexpected failures. Tier 1, Tier 2, and Tier 3 testing is the primary mechanism for | ||
| finding these issues. | ||
| - **Dual-stream cluster provisioning:** Clusters with mixed RHCOS9.8 and RHCOS10.2 worker | ||
| - **Dual-stream cluster provisioning:** Clusters with mixed RHCOS9.x and RHCOS10.x worker | ||
| nodes require specific provisioning tooling. DevOps QE to provide this capability. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
LOW — Use one provisioning status throughout the STP.
This section says DevOps QE will provide dual-stream tooling. Later sections say the tooling has been provided and validated. Use one status consistently. If provisioning is still unstable, document the remaining dependency and impact instead of marking it resolved.
As per coding guidelines, completed and pending entry criteria and dependencies must be marked accurately.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md` around lines 97 -
101, Align the dual-stream cluster provisioning status across the STP: update
the “DevOps QE to provide this capability” statement to match the later
sections’ documented status, or consistently identify the tooling as pending if
it remains unstable. Ensure all related entry criteria and dependencies
accurately distinguish completed versus outstanding work.
Source: Coding guidelines
| - [x] **Upgrade Testing** — Out of scope for this STP. | ||
| - *Details:* Upgrade testing will be covered in the CNV-5.1 . |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
LOW — Mark out-of-scope Upgrade Testing as not applicable.
This row is marked [x] but states that Upgrade Testing is out of scope. Use [ ] for a non-applicable test type. Use [x] only when the type is applicable and addressed.
As per coding guidelines, checklist state must accurately show completed versus non-applicable items. Based on learnings, this repository uses [ ] for non-applicable test types.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md` around lines 221 -
222, Update the Upgrade Testing checklist item in the STP document from [x] to [
] because it is explicitly out of scope, while preserving its existing details
and wording.
Sources: Coding guidelines, Learnings
| - RHCOS 10.x with FIPS enabled fails on cloud platforms (PSI, IBM-BM) — | ||
| tracked in [OCPBUGS-64660](https://redhat.atlassian.net/browse/OCPBUGS-64660). | ||
| - **Mitigation:** | ||
| - Use bare metal cluster with FIPS enabled. | ||
| - Engage QE DevOps team early to confirm dual-stream cluster availability timeline. Identify a | ||
| fallback of manually provisioning a mixed-node cluster if tooling is delayed. Track | ||
| provisioning readiness as an entry criterion. | ||
| - *Missing or unavailable environments:* Dual-stream cluster if QE DevOps tooling is not ready. | ||
| - Use bare metal cluster with FIPS enabled (primary test environment). | ||
| - *Missing or unavailable environments:* Cloud platforms with FIPS until OCPBUGS-64660 is fixed. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
HIGH — Resolve the Cloud Testing and environment contradiction.
Cloud Testing is marked required for the 4.22 Tech Preview and 5.0 GA. The risk section says FIPS-enabled cloud platforms are unavailable, and the environment defines bare metal as the primary environment. State that cloud testing is optional or out of scope until OCPBUGS-64660 is fixed, or add a supported FIPS-enabled cloud environment and execution criteria.
As per coding guidelines, risks and test environments must state concrete constraints, mitigation, and supported test conditions.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~318-~318: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...S-64660). - Mitigation: - Use bare metal cluster with FIPS enabled (primary test...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@stps/sig-virt/dual-stream-cluster-rhcos9-rhcos10/stp.md` around lines 315 -
319, Resolve the contradiction between required Cloud Testing and the FIPS
cloud-platform limitation in the risk and environment sections of stp.md. Until
OCPBUGS-64660 is fixed, explicitly mark cloud testing as optional or out of
scope and retain bare metal as the supported FIPS test environment, or define a
supported FIPS-enabled cloud environment with clear execution criteria.
Source: Coding guidelines
7 participants
STP Metadata
update dual stream stp for cnv-5.0
VEP issue: https://redhat.atlassian.net/browse/CNV-84749
What this PR does
Special notes for your reviewer
Summary by CodeRabbit