Stp cbt

[dalia-frank]

STP Metadata

VEP issue: https://github.com/kubevirt/enhancements/blob/main/veps/sig-storage/incremental-backup.md

What this PR does

Adds the CBT (Changed Block Tracking) STP for CNV-61530

Special notes for your reviewer

Summary by CodeRabbit

• Documentation
  • Added comprehensive CBT (Changed Block Tracking) Quality Engineering Plan document, including test strategy, scope, environment specifications, test scenarios, requirements traceability, risk assessment, and quality assurance processes for OpenShift virtualization.

[coderabbitai]

Walkthrough

A new comprehensive CBT (Changed Block Tracking) Quality Engineering Plan document for OpenShift virtualization testing. Defines metadata, feature overview, motivation, requirements, Software Test Plan (STP) with scope, strategy, environment specifications, risk assessment, known limitations, and traceability mapping to Jira requirements.

Changes

Cohort / File(s)

Summary

CBT Quality Engineering Plan stps/sig-storage/cbt.md

New comprehensive QE plan document covering CBT feature testing for OpenShift virtualization. Includes test strategy (functional, automation, compatibility, regression), detailed STP with scope (P0–P2 priorities), test environment specifications (OpenShift version, CNV, HCO gate requirements), entry criteria, risk assessment, known limitations, and traceability matrix linking Jira requirements to test scenarios. Includes sign-off sections for reviewers and approvers.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~30 minutes

🚥 Pre-merge checks | ✅ 3 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'Stp cbt' is vague and non-descriptive, using abbreviations without context that don't convey meaningful information about the changeset to someone scanning history.	Expand the title to be more descriptive, such as 'Add CBT (Changed Block Tracking) Software Test Plan for OpenShift virtualization' or similar, clearly indicating it's adding a test plan document.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into main

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

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

No actionable comments were generated in the recent review. 🎉

🧹 Recent nitpick comments

stps/sig-storage/cbt.md (3)

78-83: Fill or remove PM/Lead agreement checkboxes.

The out-of-scope table includes placeholder checkboxes [ ] Name/Date that are currently empty. These should either be filled with actual sign-offs or removed if not required for this draft stage.

---

117-124: Populate or mark the Testing Tools table as TBD.

The Testing Tools & Frameworks table is currently empty for all categories (Test Framework, CI/CD, Other Tools). Consider either populating this with the relevant tools or explicitly marking it as "TBD" if the tooling decisions are pending.

---

158-171: Follow the repository convention for requirement IDs in the traceability table.

All requirement IDs are currently marked as "TBD". Based on learnings, when multiple test scenarios fall under the same epic, use the epic ID format CNV-61530 (epic) in the first row (line 160), then leave the Requirement ID cells empty for subsequent rows (lines 161-170) to avoid redundancy.

Based on learnings: In the openshift-virtualization-tests-design-docs repository, when documenting test scenarios where multiple test scenarios fall under the same epic, it's acceptable and preferred to leave the Requirement ID cells empty for subsequent rows after the first row which contains the epic ID.

📋 Proposed update to follow repository convention

 | Requirement ID | Requirement Summary | Test Scenario(s) | Tier | Priority |
 |:----------------|:--------------------|:------------------|:-----|:---------|
-| TBD             | CBT enable/disable and VM/VMI status | Enable CBT on VM; verify VM/VMI status. Disable CBT; verify behavior and status. | T1 | P0 |
-| TBD             | Push-mode full backup and integrity | Run full backup in push mode to user PVC. Validate backup integrity (e.g. restore verification). | T1 | P0 |
-| TBD             | Incremental backup with VirtualMachineBackupTracker | Create backup tracker; run full backup then incremental backup. Verify only changed blocks. | T1 | P0 |
-| TBD             | Full and incremental backup with Windows VM | Run full then incremental backup for Windows VM. Validate backup and integrity. | T3 | P0 |
-| TBD             | CBT on OCP 4.22 with HCO feature gate | Verify CBT flows on OCP 4.22 with HCO feature gate for CBT enabled. | T2 | P0 |
-| TBD             | ForceFullBackup when tracker has checkpoint | With existing tracker/checkpoint, trigger ForceFullBackup. Verify full backup is produced. | T1 | P1 |
-| TBD             | Backup when PVC is full or insufficient | Use full or too-small backup PVC. Verify error returned and no partial backup. | T1 | P1 |
-| TBD             | Backup on different StorageClasses | Run backup with RWO/RWX and block/filesystem StorageClasses. Verify success and behavior. | T1 | P1 |
-| TBD             | Pull-mode backup | Run backup in pull mode (NBD export, scratch PVC). Verify backup completes and integrity. | T2 | P2 |
-| TBD             | Checkpoint redefinition after VM restart; full backup fallback | After VM restart, verify checkpoint redefinition. After crash/corrupted bitmap, verify full backup fallback. | T2 | P2 |
-| TBD             | Migration and backup mutually exclusive | Start backup; attempt migration (or vice versa). Verify they are mutually exclusive. | T1 | P2 |
+| CNV-61530 (epic) | CBT enable/disable and VM/VMI status | Enable CBT on VM; verify VM/VMI status. Disable CBT; verify behavior and status. | T1 | P0 |
+|                 | Push-mode full backup and integrity | Run full backup in push mode to user PVC. Validate backup integrity (e.g. restore verification). | T1 | P0 |
+|                 | Incremental backup with VirtualMachineBackupTracker | Create backup tracker; run full backup then incremental backup. Verify only changed blocks. | T1 | P0 |
+|                 | Full and incremental backup with Windows VM | Run full then incremental backup for Windows VM. Validate backup and integrity. | T3 | P0 |
+|                 | CBT on OCP 4.22 with HCO feature gate | Verify CBT flows on OCP 4.22 with HCO feature gate for CBT enabled. | T2 | P0 |
+|                 | ForceFullBackup when tracker has checkpoint | With existing tracker/checkpoint, trigger ForceFullBackup. Verify full backup is produced. | T1 | P1 |
+|                 | Backup when PVC is full or insufficient | Use full or too-small backup PVC. Verify error returned and no partial backup. | T1 | P1 |
+|                 | Backup on different StorageClasses | Run backup with RWO/RWX and block/filesystem StorageClasses. Verify success and behavior. | T1 | P1 |
+|                 | Pull-mode backup | Run backup in pull mode (NBD export, scratch PVC). Verify backup completes and integrity. | T2 | P2 |
+|                 | Checkpoint redefinition after VM restart; full backup fallback | After VM restart, verify checkpoint redefinition. After crash/corrupted bitmap, verify full backup fallback. | T2 | P2 |
+|                 | Migration and backup mutually exclusive | Start backup; attempt migration (or vice versa). Verify they are mutually exclusive. | T1 | P2 |

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[openshift-virtualization-qe-bot-4]

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, conflict labels
5. Verified: PR must be marked as verified (if verification is enabled)

📊 Review Process

Approvers and Reviewers

Approvers:

• jpeimer

Reviewers:

• Ahmad-Hafe
• dalia-frank
• duyanyan
• josemacassan
• jpeimer
• kgoldbla
• kshvaika
• stesrn

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.