Skip to content

[Infra] virtual machine template STP#34

Open
RoniKishner wants to merge 2 commits intoRedHatQE:mainfrom
RoniKishner:vm-template-stp
Open

[Infra] virtual machine template STP#34
RoniKishner wants to merge 2 commits intoRedHatQE:mainfrom
RoniKishner:vm-template-stp

Conversation

@RoniKishner
Copy link
Copy Markdown

@RoniKishner RoniKishner commented Feb 16, 2026

STP Metadata

VEP issue: https://github.com/kubevirt/enhancements/blob/main/veps/sig-compute/76-vmtemplates/vmtemplate-proposal.md

What this PR does

Add STP for new virtual machine template CRD

DCO

Signed-off-by: Roni Kishner rkishner@redhat.com

Summary by CodeRabbit

  • Documentation
    • Added a comprehensive test plan for VirtualMachine templating covering end-to-end workflows (process/convert/create), VM creation from images or existing VMs, parameter substitution, cross-namespace usage, RBAC and instance-type/preferences integration, admission-time validation and feature-gate behavior, prioritized test tiers, environment/operator prerequisites, explicit out-of-scope items, traceability, risks, and a GA readiness checklist.

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Feb 16, 2026

Note

Reviews paused

It 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 reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review
📝 Walkthrough

Walkthrough

Adds a new Software Test Plan document detailing test scope, scenarios, environment requirements, entry criteria, risks, and GA readiness checks for native in-cluster VirtualMachineTemplate and VirtualMachineTemplateRequest functionality (feature-gated Template support).

Changes

Cohort / File(s) Summary
Test Plan Documentation
stps/sig-infra/virtual-machine-template.md
Adds a comprehensive Software Test Plan covering terminology, feature overview, Tech Preview/feature-gate context, requirements/limitations (including template flattening), SIG responsibilities, in-scope functional coverage (template/VMTR lifecycle, parameter substitution, server-side /process and /create, virtctl template subcommands, VM creation from golden-image and VM-derived templates, cross-namespace usage, RBAC, instance-types/preferences integration, admission-time validation, behavior when Template feature-gate is disabled/toggled), out-of-scope items, test strategy/environment setup (operator with feature gate), tiered scenario-to-issue traceability (CNV-73392), entry criteria, risks, and GA readiness checklist.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title '[Infra] virtual machine template STP' directly and accurately summarizes the main change: adding a Software Test Plan document for virtual machine templates under the sig-infra domain.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Tip

💬 Introducing Slack Agent: The best way for teams to turn conversations into code.

Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.

  • Generate code and open pull requests
  • Plan features and break down work
  • Investigate incidents and troubleshoot customer tickets together
  • Automate recurring tasks and respond to alerts with triggers
  • Summarize progress and report instantly

Built for teams:

  • Shared memory across your entire org—no repeating context
  • Per-thread sandboxes to safely plan and execute work
  • Governance built-in—scoped access, auditability, and budget controls

One agent for your entire SDLC. Right inside Slack.

👉 Get started


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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@RoniKishner RoniKishner changed the title Add virtual machine template STP [Infra] virtual machine template STP Mar 23, 2026
@RoniKishner RoniKishner force-pushed the vm-template-stp branch 2 times, most recently from 6ad3f93 to ff38850 Compare March 23, 2026 12:56
@RoniKishner RoniKishner marked this pull request as ready for review March 23, 2026 12:56
@openshift-virtualization-qe-bot-2
Copy link
Copy Markdown

Report bugs in Issues

Welcome! 🎉

This pull request will be automatically processed with the following features:

🔄 Automatic Actions

  • Reviewer Assignment: Reviewers are automatically assigned based on the OWNERS file in the repository root
  • Size Labeling: PR size labels (XS, S, M, L, XL, XXL) are automatically applied based on changes
  • Issue Creation: A tracking issue is created for this PR and will be closed when the PR is merged or closed
  • Branch Labeling: Branch-specific labels are applied to track the target branch
  • Auto-verification: Auto-verified users have their PRs automatically marked as verified
  • Labels: Enabled categories: branch, can-be-merged, cherry-pick, has-conflicts, hold, needs-rebase, size, verified, wip

📋 Available Commands

PR Status Management

  • /wip - Mark PR as work in progress (adds WIP: prefix to title)
  • /wip cancel - Remove work in progress status
  • /hold - Block PR merging (approvers only)
  • /hold cancel - Unblock PR merging
  • /verified - Mark PR as verified
  • /verified cancel - Remove verification status
  • /reprocess - Trigger complete PR workflow reprocessing (useful if webhook failed or configuration changed)
  • /regenerate-welcome - Regenerate this welcome message

Review & Approval

  • /lgtm - Approve changes (looks good to me)
  • /approve - Approve PR (approvers only)
  • /assign-reviewers - Assign reviewers based on OWNERS file
  • /assign-reviewer @username - Assign specific reviewer
  • /check-can-merge - Check if PR meets merge requirements

Testing & Validation

  • /retest tox - Run Python test suite with tox
  • /retest all - Run all available tests

Cherry-pick Operations

  • /cherry-pick <branch> - Schedule cherry-pick to target branch when PR is merged
    • Multiple branches: /cherry-pick branch1 branch2 branch3

Label Management

  • /<label-name> - Add a label to the PR
  • /<label-name> cancel - Remove a label from the PR

✅ Merge Requirements

This PR will be automatically approved when the following conditions are met:

  1. Approval: /approve from at least one approver
  2. LGTM Count: Minimum 2 /lgtm from reviewers
  3. Status Checks: All required status checks must pass
  4. No Blockers: No wip, hold, has-conflicts labels and PR must be mergeable (no conflicts)

📊 Review Process

Approvers and Reviewers

Approvers:

  • RoniKishner
  • geetikakay

Reviewers:

  • RoniKishner
  • geetikakay
Available Labels
  • hold
  • verified
  • wip
  • lgtm
  • approve

💡 Tips

  • WIP Status: Use /wip when your PR is not ready for review
  • Verification: The verified label is automatically removed on each new commit
  • Cherry-picking: Cherry-pick labels are processed when the PR is merged
  • Permission Levels: Some commands require approver permissions
  • Auto-verified Users: Certain users have automatic verification and merge privileges

For more information, please refer to the project documentation or contact the maintainers.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@stps/sig-infra/virtual-machine-template.md`:
- Line 120: Update the table row containing the "Compute Resources" entry so the
environment requirement uses the proper noun capitalization: change the cell
text "Sufficient for windows VM and snapshot/clone operations." to "Sufficient
for Windows VM and snapshot/clone operations." Locate the row that starts with
"**Compute Resources**" in virtual-machine-template.md and replace the lowercase
"windows" with "Windows" to correct the casing.
- Around line 74-84: Ensure priority tiers are consistent between the "Testing
Goals" list and the traceability matrix by picking a single priority for each
scenario and updating both sections to match; specifically reconcile entries
such as "Verify virt-operator deploys virt-template", "Verify cross-namespace:
template in namespace A, VM creation in namespace B", and other duplicated
scenarios (e.g., virtctl template convert/create, golden-image template flow) so
each scenario appears once with the agreed priority in both the Testing Goals
and the traceability matrix; update the priority tags (P0/P1/P2) for the
duplicated items and run a diff to confirm no mismatches remain.
🪄 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: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 63370dec-8dd4-40e9-b1da-760b84ee2256

📥 Commits

Reviewing files that changed from the base of the PR and between de81e3d and ff38850.

📒 Files selected for processing (1)
  • stps/sig-infra/virtual-machine-template.md

Comment thread stps/sig-infra/virtual-machine-template.md Outdated
Comment thread stps/sig-infra/virtual-machine-template.md Outdated
Comment thread stps/sig-infra/virtual-machine-template.md
@geetikakay
Copy link
Copy Markdown

I have few comments

  1. Possibly a test case: VAP rejects VMTR when creator lacks permission
    Reference from VEP : To validate that the user creating the VirtualMachineTemplateRequest has appropriate permissions to create a template from the original VirtualMachine (reading its definition and snapshotting it), suitable ValidatingAdmissionPolicy objects will be provided to check the permissions of the user before creation of the VirtualMachineTemplateRequest is allowed. If the user does not have sufficient permissions the creation must be rejected.

  2. Should we add a section defining what goes in tier1, what comes under sig-infra and sig-virt?

  3. Featuregate disable and toggle scenarios(rollback)

coderabbitai[bot]
coderabbitai Bot previously approved these changes Apr 23, 2026
coderabbitai[bot]
coderabbitai Bot previously approved these changes Apr 29, 2026
Comment thread stps/sig-infra/virtual-machine-template.md Outdated
Comment thread stps/sig-infra/virtual-machine-template.md
Comment thread stps/sig-infra/virtual-machine-template.md Outdated
Comment thread stps/sig-infra/virtual-machine-template.md Outdated
Copy link
Copy Markdown
Contributor

@rnetser rnetser left a comment

Choose a reason for hiding this comment

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

I havne't reviwed the stp but from an overview it contains low level implementation details; an stp is a high level plan
the text should be phrased from end user perspective and not reference CRD names etc
for example
Verify virtctl template create: generates a VirtualMachineTemplateRequest from existing VM; async flow completes and template is ready for process/create.
an end user does not care about these details; As an admin, I can create VM templates from the cli or something similar.

Comment thread stps/sig-infra/virtual-machine-template.md Outdated
coderabbitai[bot]
coderabbitai Bot previously approved these changes May 3, 2026
coderabbitai[bot]
coderabbitai Bot previously approved these changes May 3, 2026
Comment thread stps/sig-infra/virtual-machine-template.md Outdated
Comment thread stps/sig-infra/virtual-machine-template.md Outdated
Comment thread stps/sig-infra/virtual-machine-template.md Outdated
Comment thread stps/sig-infra/virtual-machine-template.md Outdated
Comment thread stps/sig-infra/virtual-machine-template.md Outdated
Comment thread stps/sig-infra/virtual-machine-template.md Outdated
- *PM/Lead Agreement:* [Dominik Holler] / 1.5.2026

- **UI testing**
- *Rationale:* Good to have at Tech Preview stage.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

not sure what it means; will there be ui testing? is the ui team involved?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

We already have some, I removed any mention to UI

Comment thread stps/sig-infra/virtual-machine-template.md Outdated
- *Priority:* P2

- **[CNV-73392]** — As a cluster admin, I want template workflows to recover after I re-enable the Template capability
- *Test Scenario:* [Tier 2] Enable the capability and create baseline templates and capture requests; disable and re-enable the capability; confirm existing objects are handled predictably and supported workflows work again.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

confirm existing objects are handled predictably and supported workflows work again. - this is low level
should be something like create a new VM from a template successfully" - btw - why is this tier2?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

This is about disabling and enabling the feature repeatedly

Comment thread stps/sig-infra/virtual-machine-template.md Outdated
coderabbitai[bot]
coderabbitai Bot previously approved these changes May 7, 2026
Assisted-by: Cursor
Signed-off-by: rkishner <rkishner@redhat.com>
coderabbitai[bot]
coderabbitai Bot previously approved these changes May 7, 2026
#### **1. Requirement & User Story**

- [x] **Review Requirements**
- Native data source and existing-VM templating, cross-namespace creation, RBAC for template/VM creation.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

please rephrase as requirements review summary
e.g
capturing templates from existing VMs
the requirement for each item is not clear

- A cluster user owner can create a VM from a native in-cluster template.
- A cluster user can share native in-cluster templates between namespaces they control.
- A cluster user can still create VMs from OpenShift Templates in the web console, VM templates are available alongside those options and do not remove or replace them.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

RBAC-related acceptance criteria is missing


- [x] **Non-Functional Requirements (NFRs)**
- **Security:** Verify template processing and VM creation flows do not pass Secrets or ConfigMaps unintentionally to created VMs.
- **Performance/Scalability:** Verify a large quantity of VMs can be created from native VM templates without failures, excessive delays, or service instability.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

the out of scope includes perf as something that will not be tested. please add a ref here to this section

- **Performance/Scalability:** Verify a large quantity of VMs can be created from native VM templates without failures, excessive delays, or service instability.
- **Monitoring:** Verify no unexpected critical alerts are introduced during template processing and bulk VM creation workflows.
- *Note any NFRs not covered and why:*
- UI: updated templates display is validated by the UI team.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

please add a link to the ui epic

- The feature is deployed by the cluster operator via a feature gate in 4.22.0, and plans to be deployed by default on 4.23.0+.
- *Impact on testing approach:* All `virtctl template` and API tests run on **CNV 4.22.0+** clusters with the feature gate active.

- [x] **API Extensions**
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

this comment was not addressed
e.g Feature-toggle tests are required to verify expected behavior when template workflows are enabled, disabled, and re-enabled. is not related to this section and is already mentioned above

Comment on lines +106 to +107
- **OpenShift Virtualization 4.21**
- `virt-operator` can be installed manually for early integration and developer-level validation.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

why is this related to the stp? is the team planning on testing 4.21?

Comment on lines +118 to +120
- **Backporting approach for this feature**
- New feature scope is delivered in new versions (for example, 4.22 -> 5.0), based on the VEP implementation roadmap.
- Backports to earlier versions are expected to be limited to selected high-priority fixes, not new user-facing capabilities.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

there's already a section about feature maturity
and this describes a generic backport approach
please keep the stp simple and remove anything that is not directly tied to the feature

Comment on lines +126 to +129
#### **SIG responsibilities**

- **sig-infra** — VirtualMachineTemplate and VirtualMachineTemplateRequest API behavior, and cluster operator deployment of the template feature when the Template feature gate is enabled.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

this can be dropped as the stp is only for the infra team (there are no other sigs involved - based on the metadata above)

Comment on lines +134 to +148
- **[P0]** As a cluster admin, when I enable the Template capability on the cluster, I can define templates, process them with parameters, and run the supported create and capture workflows end to end.
- **[P0]** As a template author, I can save reusable VM designs and supply parameters so new VMs receive the intended CPU, memory, disk, and boot configuration reflected in the resulting workload.
- **[P0]** As a VM owner, after I ask the cluster to capture a template from a VM I am allowed to manage, I see a clear success or failure outcome with an understandable message; on success I can use the new template in the expected namespace.
- **[P0]** As a VM owner, I can create a runnable VM from a template using supported automation (declarative apply and CLI-based “render then create” flows), in the intended namespace, with correct boot and storage.
- **[P0]** As a VM owner, I can create a VM from a template that points at a namespaced boot source and get correct storage and boot behavior.
- **[P0]** As a cluster admin, I can restrict which users may create VMs from which templates; template owners and VM owners see permissions that match the enhancement’s access model.
- **[P1]** As a template owner, I can convert an existing OpenShift Template that contains a VM into a native VM template without losing parameters customers rely on.
- **[P1]** As a VM owner or admin, I can start template-from-VM capture from the CLI for a VM I manage; when the operation finishes, the new template is ready to process and to create VMs from.
- **[P1]** As a VM owner, templates honor sizing profiles and preferences so VMs created from the template pick up the chosen shapes and defaults.
- **[P1]** As a Windows VM owner, I can build a Windows-oriented template and create a new guest that boots with the expected disks, network, and Windows-specific settings.
- **[P1]** As a cluster admin, templates and in-flight capture requests survive cluster upgrade and remain usable afterward.
- **[P2]** As a VM owner, I can keep a template in one namespace and create a VM in another namespace where cross-namespace creation is supported (for example via rendered manifests applied with standard tooling).
- **[P2]** As a cluster admin, when required parameters have defaults, the cluster rejects template definitions that would always produce an invalid VM, while still accepting sound templates.
- **[P2]** As a cluster admin, when the Template capability is turned off, customers cannot start new template workflows until it is turned back on.
- **[P2]** As a cluster admin, when I disable and re-enable the Template capability, existing templates and capture requests are handled predictably and supported workflows work again after re-enable.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

testing goals should not be a 1-1 to test scnerios.
proposed consolidation (done by claude, please check):

   - **[P0]** As a VM owner, I can create a runnable VM from a template
     backed by a boot source, with correct CPU, memory, disk, and boot
     configuration — using both declarative and CLI-driven flows.
   - **[P0]** As a VM owner, I can capture a template from an existing VM
     and see clear success or failure; on success the template is reusable
     in the expected namespace.
   - **[P0]** As a cluster admin, I can restrict which users may create or
     capture templates and which may create VMs from them.
   - **[P1]** As a template owner, I can convert an OpenShift Template that
     contains a VM into a native VM template without losing customer-facing
     parameters.
   - **[P1]** As a VM owner, templates honor sizing profiles and preferences
     so created VMs pick up the chosen shapes and defaults.
   - **[P1]** As a Windows VM owner, I can build a Windows-oriented template
     and create a guest that boots with expected disks, network, and
     Windows-specific settings.
   - **[P1]** As a cluster admin, templates and in-flight capture requests
     survive cluster upgrade and remain usable afterward.
   - **[P2]** As a VM owner, I can use a template from another namespace to
     create a VM where cross-namespace creation is supported.
   - **[P2]** As a cluster admin, when I disable and re-enable the Template
     capability, workflows are blocked while disabled and recover
     predictably after re-enable; the cluster rejects template definitions
     that would always produce an invalid VM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

10 participants