jmsperu commented on PR #13074: URL: https://github.com/apache/cloudstack/pull/13074#issuecomment-4621388328
@abh1sar — expanded Test Plan below. Results will follow as a separate comment once I've run the manual scenarios end-to-end against the same Trillian baseline (tid-16197). ## Test plan ### Environment - Branch `feature/nas-backup-incremental` against `main` (4.23-SNAPSHOT) - KVM on OL8 (Trillian `ol8 mgmt + kvm-ol8` profile) - File-based primary storage (qcow2 on NFS); NAS repo on a separate NFS share - libvirt 9.x + qemu 7.x+ (dirty bitmaps + `backup-begin --checkpointxml`) ### Automated coverage | Layer | Suite | Cases | |---|---|---| | Unit | `NASBackupProviderTest` | 15 total, 5 new: chain decision under master switch / no-active-checkpoint, restore-clears-checkpoint, delete-with-live-child marks pending-delete, leaf-delete sweeps up pending parent | | Unit | `LibvirtRestoreBackupCommandWrapperTest` | stubs added for incremental restore path | | Smoke (Trillian) | `test/integration/smoke/test_backup_recovery_nas.py` | 5 new cases, all `required_hardware="true"` | #### Smoke scenarios | Case | What it asserts | |---|---| | `test_incremental_chain_cadence` | With `nas.backup.full.every=3` and 5 backups, observed type sequence is `['FULL','INCREMENTAL','INCREMENTAL','FULL','INCREMENTAL']` | | `test_restore_from_incremental` | Marker files written between each backup are all present after restoring from the tail INC | | `test_delete_middle_incremental_repairs_chain` | After deleting a middle INC, child's `parent_id` is repointed to the surviving ancestor, backing file is rebased, downstream restore still correct | | `test_refuse_delete_full_with_children` | Deleting a FULL that has descendants → `CloudRuntimeException`; `forced=true` cascades | | `test_stopped_vm_falls_back_to_full` | Stopped VM → next backup is FULL, no checkpoint XML in agent command | ### Manual scenarios (outside smoke scope) | # | Scenario | Method | Expected | |---|---|---|---| | A | Long-run cadence stability | `full.every=10`; take 25 backups across 5 days | FULLs at positions 1, 11, 21; INCs at all others; no chain drift | | B | 4.22 agent ↔ 4.23 mgmt | Run a 4.22 agent against the 4.23 mgmt; take backup of a VM on that host | FULL succeeds; no new flags emitted in agent command; `backup_details` carries no chain keys | | C | Master-switch flip mid-chain | After a chain has formed, set `nas.backup.incremental.enabled=false` zone-scoped | Next backup is FULL regardless of cadence; new chain anchored | | D | Bitmap recreation after VM stop/start | Take FULL+INC, stop and start the VM, take next INC | Agent recreates checkpoint via `virsh checkpoint-create`; INC succeeds; restore from this INC is correct | | E | Relative-path rebase survives mount churn | Unmount/remount the NAS at a different mount point between backup and restore | Relative backing paths keep the chain valid | | F | `nasbackup.sh` legacy invocation | Invoke without `-M` / `--bitmap-*` | Behaves byte-for-byte as 4.22; no checkpoint side-effects | ### Backwards-compat checks - `TakeBackupCommand` new fields default null → 4.22 agents ignore them (covered by Scenario B). - Pre-PR backups with no `chain_id` in `backup_details` are treated as standalone FULLs; cascade-delete short-circuits without touching them. - `RebaseBackupCommand` is only sent when chain metadata is present, so a downgraded agent never receives it. ### Results Test results from running this plan will be posted as a follow-up comment after execution. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
