infra: update virt template vm creation test case - #131
Open
RoniKishner wants to merge 1 commit into
Open
Conversation
|
Warning Review limit reached
Next review available in: 23 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe VM template design document updates direct creation checks and expands default-parameter scenarios. The changes add validation for instance type references, namespace placement, VM provisioning, actionable admission errors, and prevention of partial templates. ChangesVM template coverage
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
Suggested labels: 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. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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-infra/virtual-machine-template.md`:
- Line 237: Update the Tier 2 create-from-template scenario description to
define observable pass/fail outcomes: verify the VM’s CPU, memory, disk, and
boot configuration match the selected common instance type, confirm placement in
the expected namespace, and specify both authorized and unauthorized access
results.
🪄 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
Run ID: 002b32ca-41cd-4fb8-9786-39a1fa69e761
📒 Files selected for processing (1)
stps/sig-infra/virtual-machine-template.md
Contributor
|
/lgtm |
RoniKishner
force-pushed
the
virt-template-update
branch
from
July 29, 2026 07:50
9af5573 to
e7b3413
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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-infra/virtual-machine-template.md`:
- Around line 272-281: Rewrite the three CNV-73392 scenarios as
template-author-observable outcomes: saving valid defaults succeeds, creating a
VM from those defaults produces the expected workload, and invalid defaults are
clearly rejected without saving an unusable template. Remove references to
VirtualMachineTemplate, VirtualMachine, admission errors, and resource/API
operations while preserving the existing test IDs and priorities.
🪄 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: 4bb08c9a-6e4b-4bd2-ac8c-604745f3a5f0
📒 Files selected for processing (3)
.pre-commit-config.yamlAGENTS.mdstps/sig-infra/virtual-machine-template.md
RoniKishner
force-pushed
the
virt-template-update
branch
from
July 29, 2026 07:54
e7b3413 to
adf856e
Compare
RoniKishner
force-pushed
the
virt-template-update
branch
from
July 29, 2026 07:59
adf856e to
3b35066
Compare
rnetser
requested changes
Aug 3, 2026
RoniKishner
force-pushed
the
virt-template-update
branch
from
August 5, 2026 13:21
ac4f33d to
6a36e75
Compare
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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-infra/virtual-machine-template.md`:
- Around line 276-278: Expand the CNV-16336 test scenario with explicit default
parameter names, their expected rendered values, and the resource under test (VM
or VMI). Replace the vague “specified fields” wording with observable pass/fail
assertions for each default value.
🪄 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: 649a5fa0-27f4-4ab0-a177-8a887a27e28e
📒 Files selected for processing (1)
stps/sig-infra/virtual-machine-template.md
🔗 Linked repositories identified
CodeRabbit considers these linked repositories for cross-repo context during reviews:
RedHatQE/openshift-virtualization-tests(manual) → reviewed against open PR#5764vm-template-admissioninstead of the default branch
📜 Review details
🧰 Additional context used
📓 Path-based instructions (3)
**/*.md
📄 CodeRabbit inference engine (CLAUDE.md)
Adhere to markdown linting configuration defined in .markdownlint.yaml
Files:
stps/sig-infra/virtual-machine-template.md
stps/**/*.md
📄 CodeRabbit inference engine (AGENTS.md)
stps/**/*.md: Every claim in an approved STP must have evidence such as sign-offs, Jira links, or dates; placeholders must not remain.
Feature Limitations, Test Limitations, Out of Scope, and Risks must remain distinct categories and must not be mixed.
Every test scenario must map to a Jira requirement ID and include its tier and priority.
STPs must be concise and actionable, with no boilerplate, vague statements, or unremoved template content.
Metadata must include justified enhancement links, feature-level and epic Jira tracking, structured feature maturity, QE owners with contacts, correct SIG ownership, and feature-specific document conventions.
Feature Overview sections must contain 2–8 sentences, explain customer value from the user perspective, state the applicable feature phase, and avoid implementation details.
Claims in Feature Overview must have matching acceptance criteria and test scenarios, or be explicitly documented as out of scope with rationale and PM/Lead agreement.
Requirements must be specific and testable; customer use cases must use user-story format; acceptance criteria must be individual, observable pass/fail conditions.
Seamless or non-disruptive behavior must include an acceptance criterion and scenario that would fail if disruption occurred, rather than checking only the final state.
NFRs must explicitly address Monitoring, Observability, UI, Documentation, Performance, Security, and Scalability, with justification for uncovered categories.
Testing Goals must use end-user language, be SMART, identify P0/P1/P2 priority, distinguish functional from regression testing, and be ordered P0 first.
Each P0 functional Testing Goal must have at least one negative or failure-path goal and a matching Section III scenario, unless the omission is documented as out of scope with PM/Lead agreement.
Testing Goals must name all configuration dimensions needed to implement the test and must justify scenarios that validate behavior only after a feature rea...
Files:
stps/sig-infra/virtual-machine-template.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-infra/virtual-machine-template.md
🧠 Learnings (21)
📚 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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.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-infra/virtual-machine-template.md
🔇 Additional comments (1)
stps/sig-infra/virtual-machine-template.md (1)
237-237: LGTM!Also applies to: 272-274, 280-281
Co-authored-by: Cursor <cursoragent@cursor.com> Signed-off-by: rkishner <rkishner@redhat.com>
RoniKishner
force-pushed
the
virt-template-update
branch
from
August 5, 2026 13:58
6a36e75 to
f05f3a4
Compare
Contributor
|
/lgtm |
0xFelix
reviewed
Aug 7, 2026
|
|
||
| - **[CNV-73392]** — As a VM owner, I want to create a VM directly from a template in one step where the product supports it | ||
| - *Test Scenario:* [Tier 1] Validate the supported single-step create-from-template flow, including expected namespace placement and access behavior. | ||
| - *Test Scenario:* [Tier 2] Validate the supported create-from-template flow using a common instance type: the resulting VM references the selected instance type correctly, and the VM is placed in the expected namespace. |
There was a problem hiding this comment.
Shouldn't it be a T1 test case in kubevirt/virt-template?
| - **[CNV-73392]** — As a template author, I want the cluster to reject templates that would always produce an invalid VM when defaults fill required parameters (OpenShift Virtualization 4.22) | ||
| - *Test Scenario:* [Tier 2] Validate admission behavior for invalid-by-default templates and acceptance behavior for valid templates under defaulted parameters. | ||
| - **[CNV-73392]** — As a template author, I want saving a well-formed template to succeed so I can reuse it to provision VMs | ||
| - *Test Scenario:* [Tier 2] Create a template whose default parameter values produce a complete, valid VM configuration and confirm the template is available for use. |
| - *Test Scenario:* [Tier 2] Create a template whose default parameter values produce a complete, valid VM configuration and confirm the template is available for use. | ||
| - *Priority:* P2 | ||
|
|
||
| - **[CNV-73392]** — As a VM owner, I want VMs created from my template to run as expected with the sizing and preferences I specified using instance types |
There was a problem hiding this comment.
Isn't this case a dup of the one on L237?
| - *Test Scenario:* [Tier 2] Provision a VM from a template using instance types and verify the resulting VM has the specified fields in the template. | ||
| - *Priority:* P2 | ||
|
|
||
| - **[CNV-73392]** — As a template author, I want the platform to reject a template whose defaults would always produce an unusable VM and to tell me clearly why it was rejected |
There was a problem hiding this comment.
Covered in unit/integration tests in T1 already? Could be extended in T1 too.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this PR does
Special notes for your reviewer
Relate to STD PR - RedHatQE/openshift-virtualization-tests#5460
Summary by CodeRabbit