Fix volume snapshot physical size after migration between secondary storages #12166
Conversation
|
@blueorangutan package |
|
@hsato03 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. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 4.20 #12166 +/- ##
============================================
- Coverage 16.18% 16.18% -0.01%
- Complexity 13300 13301 +1
============================================
Files 5657 5657
Lines 498478 498478
Branches 60501 60501
============================================
- Hits 80668 80664 -4
- Misses 408827 408830 +3
- Partials 8983 8984 +1
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.
Pull request overview
This PR fixes a bug where volume snapshot physical size was incorrectly set to 0 after migration between secondary storages using the migrateSecondaryStorageData and migrateResourceToAnotherSecondaryStorage APIs.
- Corrected the lookup of the destination snapshot store to use destination data store ID and snapshot ID instead of source parameters
- Aligned the snapshot handling pattern with the existing VolumeInfo and TemplateInfo handling in the same method
Comments suppressed due to low confidence (1)
engine/storage/image/src/main/java/org/apache/cloudstack/storage/image/SecondaryStorageServiceImpl.java:291
- The fixed bug in the
updateDataObjectmethod lacks test coverage. Consider adding a test case to verify that after migrating a snapshot between secondary storages, the physical size is correctly preserved. This would prevent similar regressions in the future.
private void updateDataObject(DataObject srcData, DataObject destData) {
if (destData instanceof SnapshotInfo) {
SnapshotDataStoreVO snapshotStore = snapshotStoreDao.findBySourceSnapshot(srcData.getId(), DataStoreRole.Image);
SnapshotDataStoreVO destSnapshotStore = snapshotStoreDao.findByStoreSnapshot(DataStoreRole.Image, destData.getDataStore().getId(), destData.getId());
if (snapshotStore != null && destSnapshotStore != null) {
destSnapshotStore.setPhysicalSize(snapshotStore.getPhysicalSize());
destSnapshotStore.setCreated(snapshotStore.getCreated());
if (snapshotStore.getParentSnapshotId() != destSnapshotStore.getParentSnapshotId()) {
destSnapshotStore.setParentSnapshotId(snapshotStore.getParentSnapshotId());
}
snapshotStoreDao.update(destSnapshotStore.getId(), destSnapshotStore);
}
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 15860 |
|
@blueorangutan test |
|
@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-14899)
|
|
@hsato03 should this go in 4.20 branch? |
hsato03
force-pushed
the
fix-snapshot-size-after-migration
branch
from
e81766a to
dc7c20d
Compare
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
Sure, I changed the base branch to |
|
@blueorangutan package |
|
@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. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 15941 |
|
@blueorangutan test |
|
@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-14915)
|
6 participants
Description
When migrating a volume snapshot from one secondary storage to another using the
migrateSecondaryStorageDataandmigrateResourceToAnotherSecondaryStorageAPIs, its physical size is set to0.This behavior was changed to preserve the physical size of the snapshot after migration.
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
I migrated a volume snapshot using the
migrateSecondaryStorageDataandmigrateResourceToAnotherSecondaryStorageAPIs and verified that its physical size had not changed.How did you try to break this feature and the system with this change?