Hi, I have checked both the PRs. My observations are-
Nathan, As per your implementation, - When the parameter “snapshot.backup.rightafter” is set to false, when the snapshot is created on primary, the state transitions are faked from CreatedOnPrimary -> BackingUp and BackingUp -> Backup. - For both values (true and false) of the parameter “snapshot.backup.rightafter”, the Snapshot state is backed up, which is confusing. - User doesn’t know which snapshot is backed up and physically available in secondary. - The create template or create volume (whichever is the first) is slow for the snapshot created when “snapshot.backup.rightafter” is false. The actual backup process is delayed and would be done on demand. - When snapshot on primary is backed up on demand, the state of the primary storage and the snapshot on it, is unpredictable. My proposal moves the global parameter to API level so that user can separate the backup at snapshot creation time. The snapshot backup will be triggered immediately after creation of the snapshot on primary and will be decoupled from the API async job. This unblocks the VM queue after snapshot creation on primary and enables the user to perform other allowed VM operations when snapshot is backing up in the background (which can be tracked using the snapshot state/status). Also, the snapshot state transitions will be in the proper order. Syed, - User does not choose the location where the snapshot has to be stored for unmanaged storage. In case of unmanaged storage, the snapshot should be backed up to the secondary. So locationType would be always SECONDARY for unmanaged storage, no point in using this parameter for unmanaged storage. -My proposal separates the snapshot backup for unmanaged storage only. Please let me know your comments. Thanks, Harika. From: Syed Ahmed [mailto:sah...@cloudops.com] Sent: Thursday, May 11, 2017 1:08 AM To: dev@cloudstack.apache.org Cc: Harika Punna <harika.pu...@accelerite.com> Subject: Re: [PROPOSAL] Separate creation and backup operations for a volume snapshot Oops I meant Harika, I know that Nathan you were working on something like this a while back with Ceph so I assumed you where the one who proposed this. Anyways, Harika, look at the locationType parameter in the CreateSnaphsot API command. This is what you are looking to implement. Note that this currently only works for Managed storage (SolidFire) so you'd have to work it into the standard non-managed storage. Let me know if you have any questions. Thanks, -Syed On Wed, May 10, 2017 at 3:24 PM, Syed Ahmed <sah...@cloudops.com<mailto:sah...@cloudops.com>> wrote: Hi Nathan, This option to choose between primary and secondary was added by me a while back. You want to look at https://github.com/apache/cloudstack/pull/1600 On Tue, May 9, 2017 at 10:09 AM, Nathan Johnson <njohn...@ena.com<mailto:njohn...@ena.com>> wrote: Harika Punna <harika.pu...@accelerite.com<mailto:harika.pu...@accelerite.com>> wrote: > > Currently, Volume Snapshots in Cloudstack take considerable amount of > time to complete as snapshot involves creation on primary and backup on > secondary. I would like to introduce an optional parameter in > CreateSnapshotCmd API to separate these operations. > > > More details in the FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Separate+creation+and+backup+operations+for+a+volume+snapshot > > > Thanks, > Harika. Hello Harika. There was a related discussion around a global configuration parameter snapshot.backup.rightafter See the thread here: https://issues.apache.org/jira/browse/CLOUDSTACK-4858 And here is the PR where this was merged into 4.9: https://github.com/apache/cloudstack/pull/1697 This is distinct from what you propose, and I like the idea of being able to specify whether or not to back up at snapshot creation time, versus only having a global configuration parameter. Also one remaining issue with the current implementation of snapshots and backups is that if the snapshot.backup.rightafter parameter is set to false, on doing certain operations with snapshots (create template from snapshot iirc, perhaps some others) it will then need to take the backup to secondary at that time, and it will be very slow. I think at some point you have to take that hit, so maybe there is no way around this. But that brings me to a followup point: since the PR was merged above, ACS will backup on-demand any snapshots that need to be on secondary that only exist on primary. it would be nice to also have an optional cleanup thread and an expiration of backups to secondary. Or maybe API endpoints that would allow some external management of backups. What do you think? Nathan Johnson R&D Engineer Education Networks of America DISCLAIMER ========== This e-mail may contain privileged and confidential information which is the property of Accelerite, a Persistent Systems business. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Accelerite, a Persistent Systems business does not accept any liability for virus infected mails.
