JoaoJandre commented on PR #12758:
URL: https://github.com/apache/cloudstack/pull/12758#issuecomment-4057557293
Hello, @abh1sar
> 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.
>
You can have exactly that using this implementation. Essentially backup
repositories and secondary storages are the same, with different names. Using
selectors, you can have offerings that are tied to specific secondary storages,
or you can have offerings that go into multiple storages, it was made to be
flexible.
> 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.
Again, you can have dedicated secondary storages using selectors.
> 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.
While I was not the one that introduced the backup framework, looking at its
design, it was clearly intended to have as little configuration as possible on
the ACS side while leaving these details to the backup provider. If we add
these parameters to the import backup offering API, I'm sure a lot of users
will be confused when they do nothing for Veeam and Dell Networker. I did not
intend to warp the original design of configuring the offerings on the provider
side and only importing it to ACS.
This is why I created the concept of native offerings. As with KNIB (and
NAS) the provider is ACS, and thus the configurations can still be made on the
"backup provider", and the import API will follow the same logic it always had.
> * What defines a provider as `Native`?
A provider is native if the backup implementation is made by ACS. Thus, the
current native providers would be NAS and KNIB. Veeam and Networker are
external providers.
> * Do the native offerings differ in functionality or usage to the
existing BackupOfferings?
They are used to configure the details that would be configured in the
backup provider if it was an external provider, such as Veeam for example.
> * How will this look like in the UI? Will the user see `Backup
Offering` and another `Native Backup Offering`?
I have yet to add it to the GUI, if you have any suggestions for the GUI
design, you are free to give your opinion. The GUI for the native backup
offerings will be added in the future.
> * Again, coupling an offering to storage has its benefits which
current Backup Offerings already have.
Again, you absolutely can do this with KNIB. But you may also choose not to
do it, its *flexible*.
--
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]
