rajiv-jain-netapp commented on code in PR #14255:
URL: https://github.com/apache/cloudstack/pull/14255#discussion_r4151976690
##########
server/src/main/java/org/apache/cloudstack/backup/BackupManagerImpl.java:
##########
@@ -2677,6 +2680,17 @@ public BackupResponse createBackupResponse(Backup
backup, Boolean listVmDetails)
response.setToCheckpointId(backup.getToCheckpointId());
}
+ if (KBOSS_BACKUP_PROVIDER.equals(offering.getProvider()) &&
isCallerRootAdmin) {
+ List<InternalBackupJoinVO> backupJoins =
internalBackupJoinDao.listById(backup.getId());
+ Map<String, String> backupVolumePaths = new HashMap<>();
+
+ backupJoins.forEach(b -> {
+ backupVolumePaths.put(b.getVolumeName(),
b.getImageStorePath());
Review Comment:
CloudStack does not enforce uniqueness for volume names. The same volume
name can be used across multiple VMs, and users can also rename volumes after
creation. Given this, if multiple volumes end up sharing the same name, this
put() operation could silently overwrite the path mapping for an unintended
volume, potentially resulting in incorrect path associations. you can count on
volumeUUID instead.
Additionally, considering that multiple secondary storage pools can exist
within a zone, we could optimise the map value by storing a composite
identifier that includes both the image path and the image UUID/name, rather
than just the imageStorePath. This would provide a more reliable way to
uniquely identify image locations while also improving maintainability and
future scalability.
--
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]
