abh1sar commented on PR #12758: URL: https://github.com/apache/cloudstack/pull/12758#issuecomment-4055499417
Hi @JoaoJandre Please find my response inline. > I don't see why we should force the coupling of backup offerings with backup repositories, what is the benefit? > It has a big benefit for use cases where someone wants multiple tiers of backup storage with different cost and recovery characteristics. For example, long-term archival backups might go to cheap cold storage like tape, while backups that require faster recovery (better RTO) may use more expensive SSD-backed storage. You can have multiple backup offerings for different use cases and VMs can be attached to the required offerings. Furthermore, the backup storage usage is tracked per Backup Offering. So, users can use different offerings as per requirement and get charged accordingly. > > The secondary storage also has both features. Although the capacity is not reported to the users currently. > Capacity is just for Admins for Backup Repository also, so that is not the issue. But the Secondary Storage capacity tracking and alerts would be mixed up for Templates, Snapshots, Volumes and Backups. With backup repositories, you will get separate capacity tracking and alerts just for the Backup Infrastructure. > Compression using qemu-img was a lot faster, with a bit smaller compression ratio. Furthermore, we have to consider > that the qemu-img compressed image can be used as-is, while the other images must be decompressed, further adding > to the processing time of backing up/restoring a backup. > It does have its benefits, but do keep in mind that the decompression cost will be paid by Reads. Also if someone is using a restored VM, they might see the physical size increase disproportionately to the actual data written due to decompression. It's still a useful feature and it's good that it is optional. > I did not want to add dozens of parameters to the import backup offering API which are only really going to be used for one provider. This way, the original design of the API is preserved. > If there is possibility these parameters can be added for other providers they should be added to the existing API. Some of these like allowQuickRestore, allowExtractFile might as well be added for other providers such as Veeam and NAS in the future. > Furthermore, you may note that the APIs are intentionally not called `createKnibBackupOffering`, but `createNativeBackupOffering`. If other native providers want to use these offerings, they may do so by extending their implementations. > * What defines a provider as `Native`? * Do the native offerings differ in functionality or usage to the existing BackupOfferings? * How will this look like in the UI? Will the user see `Backup Offering` and another `Native Backup Offering`? * Again, coupling an offering to storage has its benefits which current Backup Offerings already have. -- 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]
