-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Fix issue when restoring backup after migration of volume#12549
Fix issue when restoring backup after migration of volume #12549
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@ ## 4.20 #12549 +/- ## ============================================ + Coverage 16.26% 16.37% +0.10% - Complexity 13428 13622 +194 ============================================ Files 5660 5661 +1 Lines 499907 502480 +2573 Branches 60696 61846 +1150 ============================================ + Hits 81316 82267 +951 - Misses 409521 411087 +1566 - Partials 9070 9126 +56
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the new uuid or path after migration needs to be updated in the backed-up volumes metadata if any backups existing for them? any case path might also change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new UUID / path for the backed up volume doesn't need to be updated as the uuid - points to the volume UUID - which is always the same on subsequent backups, and the path points to the backup path - which shouldn't vary even if volume is migrated. I don't see the path of the backup changing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's better change to backedVolumeInfo to avoid confusion.
@Pearl1594 Correct, path of the backup doesn't change. I mean, the volume path after migration might change as the volume is checked by its backed up path (which is before migration). cc @abh1sar
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should not have path in the backed-up volumes metadata at all.
- Backup files are named suing the volume uuid
- The path in backed-up volumes is not being referenced anywhere apart from UI
volume.getPath() already gives us the path where we have to restore. I don't see a point in maintaining it in backup metadata also and updating it whenever volume path changes.
There was a PR merged on main that makes the UI reference uuid instead of path. (#12156)
So I propose removing path entirely from Backup.VolumeInfo in the main branch. We don't need upgrade handling also. The path in the DB for older backups will simply get ignored.
Now in the context of this PR, we should get the path from volume.getPath() not from backup-up volumes metadata.
Thoughts? @sureshanaparti @Pearl1594
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With respect to this statement:
Now in the context of this PR, we should get the path from volume.getPath() not from backup-up volumes metadata.
I think we need to consider backedVolume.getPath() - as a volume could have gotten migrated and the path changes. But when restoring from a backup, we need to reference the path of the backedVolume (which was the path of the volume prior to the migrate operation). Correct me if I'm wrong.
If volumeUuid is passed, then volume's uuid is used, but, when null, it uses the backupVolume path to determine the backup file as seen in : https://github.com/apache/cloudstack/blob/main/plugins/hypervisors/kvm/src/main/java/com/cloud/hypervisor/kvm/resource/wrapper/LibvirtRestoreBackupCommandWrapper.java#L224-L225
Pearl1594
commented
Jan 29, 2026
@blueorangutan package
blueorangutan
commented
Jan 29, 2026
@Pearl1594 a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.
blueorangutan
commented
Jan 29, 2026
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 16637
Pearl1594
commented
Jan 30, 2026
@blueorangutan test
blueorangutan
commented
Jan 30, 2026
@Pearl1594 a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests
plugins/backup/nas/src/main/java/org/apache/cloudstack/backup/NASBackupProvider.java
Outdated
Show resolved
Hide resolved
blueorangutan
commented
Jan 30, 2026
|
[SF] Trillian test result (tid-15340)
|
plugins/backup/nas/src/main/java/org/apache/cloudstack/backup/NASBackupProvider.java
Show resolved
Hide resolved
DaanHoogland
commented
Feb 3, 2026
@blueorangutan package
blueorangutan
commented
Feb 3, 2026
@DaanHoogland a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.
blueorangutan
commented
Feb 3, 2026
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 16686
@DaanHoogland
DaanHoogland
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clgtm
plugins/backup/nas/src/main/java/org/apache/cloudstack/backup/NASBackupProvider.java
Show resolved
Hide resolved
Pearl1594
commented
Feb 4, 2026
@blueorangutan package
@sureshanaparti
sureshanaparti
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clgtm
sureshanaparti
commented
Feb 5, 2026
@blueorangutan package
blueorangutan
commented
Feb 5, 2026
@sureshanaparti a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.
Quality Gate Failed Quality Gate failed
Failed conditions
0.0% Coverage on New Code (required ≥ 40%)
blueorangutan
commented
Feb 5, 2026
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 16710
Description
This PR fixes: #12517
Types of changes
Feature/Enhancement Scale or Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
How did you try to break this feature and the system with this change?