That's fun to see that discussion happening. I 100% agree with Paul's
points of view. VolumeSnapshot are not a backup, but I do consider them as
a safety vest against Primary Storage failure, because failure append :-( .
The current proposal around snapshots that reside on the primary storage or
snapshots that end in the Secondary Storage is not to address any kind of
backups requirement because a snapshot is not a backup, event an extracted
VM snapshot.
The main idea, and again this is for managed storage;
1. StorageSnapshotAPI: Provide storage side snapshot capability for fast
response time that support rollback to previous timestamp, create new
volume and maybe create template.
not required to be a new API if the work is already done, I think this
is a different behaviors than the user expectation of a volume-snapshot.
2. VolumeSnapshotAPI: Provide current cloudstack behavior that create an
extraction of a volume into SecondaryStorage which can be reuse to create a
new volume into another Primary Storage. This type of snapshot is a slow
job since yes it would have to copy the full volume size on the Secondary
storage.
PL
On Fri, Feb 5, 2016 at 12:45 PM, Syed Mushtaq <syed1.mush...@gmail.com>
wrote:
> I think I share you view on the 'Ideal world'. Backup (via Volume
> Snapshots) is a huge bottleneck in Cloudstack. This is amplified especially
> when you have a object storage as your secondary storage because it
> requires two copies (one to an NFS staging area and from there to object
> storage). And not to mention that all these copies are consuming hypervisor
> resources. Xenserver's Dom0 is also a huge bottleneck as all the Network
> and I/O flow through it. So our intention of proposing the "Storage
> Snapshots" is to give a better way of achiving snapshots while still
> keeping the original definition of volume snpashots (ie upload to sec
> storage).
>
> But as Erik pointed out volume snapshots are not backups. They don't work
> form multi-disk LVM volume groups and dynamic disks. I am all in for a
> better backup solution which handles these use cases and utilizes the
> storage's advanced features.
>
>
>
> On Fri, Feb 5, 2016 at 12:29 PM, Paul Angus <paul.an...@shapeblue.com>
> wrote:
>
> > In the beginning... there were CloudStack snapshots and they were
> actually
> > volume snapshots not hypervisor point-in-time snapshots.
> > Then VM snapshots were created (which are point-in-time hypervisor
> > snapshots) and we started referring to the original snapshots as volume
> > snapshots.
> >
> > CloudStack does not offer 'backups', but many people use volume snapshots
> > as backups. However you can't in-place restore volume snapshots and if
> you
> > have a VM with multiple volumes, the volume snapshots must be done in
> > series, meaning that the state across all of the volumes is unlikely to
> be
> > consistent.
> >
> > 'Actual Backups' would enable all of the restore options which users
> might
> > expect as well options as to where they might be stored. In my ideal
> world
> > they would also be able to leverage back-end hardware (such as Solidfire,
> > NetApp etc :) ) and software such as Veeam, Commvault etc to accelerate
> the
> > process.
> >
> >
> >
> > [image: ShapeBlue] <http://www.shapeblue.com>
> > Paul Angus
> > VP Technology , ShapeBlue
> > d: *+44 203 617 0528 | s: +44 203 603 0540*
> > <+44%20203%20617%200528%20%7C%20s:%20+44%20203%20603%200540> | m:
> > *+44 7711 418784* <+44%207711%20418784>
> > e: *paul.an...@shapeblue.com | t: @cloudyangus*
> > <paul.an...@shapeblue.com%20%7C%20t:%20@cloudyangus> | w:
> > *www.shapeblue.com* <http://www.shapeblue.com>
> > a: 53 Chandos Place, Covent Garden London WC2N 4HS UK
> > Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
> > Services India LLP is a company incorporated in India and is operated
> under
> > license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a
> > company incorporated in Brasil and is operated under license from Shape
> > Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
> > South Africa and is traded under license from Shape Blue Ltd. ShapeBlue
> is
> > a registered trademark.
> > This email and any attachments to it may be confidential and are intended
> > solely for the use of the individual to whom it is addressed. Any views
> or
> > opinions expressed are solely those of the author and do not necessarily
> > represent those of Shape Blue Ltd or related companies. If you are not
> the
> > intended recipient of this email, you must neither take any action based
> > upon its contents, nor copy or show it to anyone. Please contact the
> sender
> > if you believe you have received this email in error.
> >
> >
> > -----Original Message-----
> > From: Syed Mushtaq [mailto:syed1.mush...@gmail.com]
> > Sent: Friday, February 5, 2016 4:58 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [Propose][New Feature] Storage Snapshots
> >
> > Paul,
> >
> > When you say actual backups, how would it be different from the Volume
> > Snapshots that exist currently. My understanding is that Backups end up
> in
> > Sec Storage whereas Snapshots are just a point-in-time state of your
> volume
> > which can be restored back correct?
> >
> > -Syed
> >
> >
> > On Fri, Feb 5, 2016 at 11:23 AM, Paul Angus <paul.an...@shapeblue.com>
> > wrote:
> >
> > > Hi Syed,
> > >
> > > As I understand it, the SolidFire plugin will export the snapshot to
> > > secondary storage if the user requests a template from the snapshot or
> > > wants to download the snapshot from the cloud. This is a good,
> > > pragmatic approach and yes Mike the SolidFire storage is super
> > > reliable and snapshots on SolidFire arrays take up next to no space.
> > > BUT I think that we are talking about a more general purpose API, and
> > > other storage systems may not be as awesome as Mike's. That's my
> > > concern. Also, the time to transfer for say 1TB to move from primary
> > > to sec storage and then create a VM template out of it may be too long
> > for users.
> > >
> > > @Mike I don’t think 'we' use the term volume snapshot for backup, it's
> > > just that users want to do backups and a volume snapshot is the only
> > > type of snapshot that copies the disk elsewhere and can be scheduled.
> > >
> > > I'm 'pondering' the implications of enabling actual backups (through
> > > recognised backup providers) and the user requirements around them
> > > (particularly restoration use cases) as a separate thread of work.
> > >
> > >
> > >
> > >
> > >
> > > [image: ShapeBlue] <http://www.shapeblue.com> Paul Angus VP Technology
> > > , ShapeBlue
> > > d: *+44 203 617 0528 | s: +44 203 603 0540*
> > > <+44%20203%20617%200528%20%7C%20s:%20+44%20203%20603%200540> | m:
> > > *+44 7711 418784* <+44%207711%20418784>
> > > e: *paul.an...@shapeblue.com | t: @cloudyangus*
> > > <paul.an...@shapeblue.com%20%7C%20t:%20@cloudyangus> | w:
> > > *www.shapeblue.com* <http://www.shapeblue.com>
> > > a: 53 Chandos Place, Covent Garden London WC2N 4HS UK Shape Blue Ltd
> > > is a company incorporated in England & Wales. ShapeBlue Services India
> > > LLP is a company incorporated in India and is operated under license
> > > from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company
> > > incorporated in Brasil and is operated under license from Shape Blue
> > > Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
> > > South Africa and is traded under license from Shape Blue Ltd.
> > > ShapeBlue is a registered trademark.
> > > This email and any attachments to it may be confidential and are
> > > intended solely for the use of the individual to whom it is addressed.
> > > Any views or opinions expressed are solely those of the author and do
> > > not necessarily represent those of Shape Blue Ltd or related
> > > companies. If you are not the intended recipient of this email, you
> > > must neither take any action based upon its contents, nor copy or show
> > > it to anyone. Please contact the sender if you believe you have
> received
> > this email in error.
> > >
> > >
> > > -----Original Message-----
> > > From: Syed Mushtaq [mailto:syed1.mush...@gmail.com]
> > > Sent: 05 February 2016 15:31
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: [Propose][New Feature] Storage Snapshots
> > >
> > > I think the terminology confusion comes from AWS where they do EBS
> > > snapshots backed up to S3 and CloudStack sort of followed that. And as
> > > an end user who is oblivious to the internals of my provider, my
> > > expectation would be something similar to what AWS as that is my
> > > biggest reference point.
> > >
> > > To your point Mike, I agree that a Primary Storage failure on
> > > SolidFire is unlikely, there are other motivations for us to push data
> > > to secondary storage. Primary storage (atleast for us) costs around 3
> > > times as much as secondary storage and snapshots on primary storage
> > > are rarely used (especially for some of our customers who do daily
> > backups).
> > >
> > >
> > > On Fri, Feb 5, 2016 at 10:18 AM, Mike Tutkowski <
> > > mike.tutkow...@solidfire.com> wrote:
> > >
> > > > Some of the weirdness is around terminology.
> > > >
> > > > For most systems I've worked on, a snapshot and a backup are two
> > > > completely different things (but CloudStack has traditionally used
> > > > the term "volume snapshot" to mean backup).
> > > >
> > > > I will put in a SolidFire "plug" here and say, though, that if your
> > > > primary storage is running on SolidFire that it is unlikely you'll
> > > > encounter an issue where your primary storage goes offline (and
> > > > you'll even maintain your performance guarantees during failure
> > > > scenarios and upgrades, as well). That being the case, it is less
> > > > useful to require a backup to Swift (but it's perfectly OK if that's
> > > > what we want to do
> > > here).
> > > >
> > > > On Fri, Feb 5, 2016 at 8:07 AM, Syed Mushtaq
> > > > <syed1.mush...@gmail.com>
> > > > wrote:
> > > >
> > > > > Paul,
> > > > >
> > > > > I believe with the current implementation of Snapshots on managed
> > > > > storage
> > > > > (SolidFire) the snapshots are never exported to the secondary
> > storage.
> > > > > While this solves the problem of having snapshots taking forever
> > > > > to get to sec storage, this leaves us with a
> > > > huge
> > > > > liability if our primary storage goes down. We see snapshots as
> > > > > our recovery path because we store them in Swift which is reliable
> > > > > and resilient to failures.
> > > > >
> > > > > With Storage snpashots our goal is to have Volume snapshots always
> > > > > backed up to secondary storage and Storage Snapshots stay on the
> > > > > primary
> > > > storage.
> > > > > A provider could potentially mix both these and solve the problem
> > > > > that you mentioned where you want to meet user's expectation of a
> > > > > snapshot (ie backup to sec storage) while having an ability to
> > > > > utilize faster sanpshots (i.e. on the device)
> > > > >
> > > > > Hope this clarifies things.
> > > > >
> > > > > Thanks,
> > > > > -Syed
> > > > >
> > > > > On Fri, Feb 5, 2016 at 9:04 AM, Paul Angus
> > > > > <paul.an...@shapeblue.com>
> > > > > wrote:
> > > > >
> > > > > > HI guys,
> > > > > >
> > > > > > Could someone point me to the Jira bug of FS for the
> > > > > > SAN-snapshot
> > > > feature
> > > > > > in 4.6 which is mentioned.
> > > > > >
> > > > > > From my discussions with users and operators around snapshots
> > > > > > I'd make
> > > > > the
> > > > > > following observations:
> > > > > > a. 'users' use snapshots as backups (both long-term and short
> > > > > > term)
> > > > with
> > > > > > the expectation that they can use them for recovery if required.
> > > > > > b. operators fall back to snapshots if something has gone wrong
> > > > > > with primary storage.
> > > > > > c. users sometimes want to be able to export snapshots as well
> > > > > > as
> > > > create
> > > > > > new VMs from their snapshots
> > > > > > d. snapshots are a currently a massive pain for operators, I
> > > > > > know at
> > > > > least
> > > > > > one public cloud who have snapshots which take 2 days to
> complete.
> > > > > > e. snapshots (as they are) can't be used for multiple LVM disks.
> > > > > >
> > > > > > I think the process Mike has used in the SolidFire plugin (only
> > > > > > moving
> > > > > the
> > > > > > disk image to secondary storage when you absolutely have to) is
> > > > > > a very
> > > > > good
> > > > > > and pragmatic solution. I wonder what problems an operator might
> > > > > experience
> > > > > > if they have an issue with a given primary storage pool in a
> > cluster.
> > > > (I
> > > > > > know that that is REALLY unlikely in the SolidFire case Mike :)
> > > > > > ) And
> > > > if
> > > > > > the transfer from primary to secondary is slow, the time to
> > > > > > being able
> > > > to
> > > > > > create a template or export the volume will be slow.
> > > > > >
> > > > > > So for me the issue is around making sure that the end users
> > > > expectations
> > > > > > are met (while improving the speed/efficiency of the back end)
> > > > > >
> > > > > >
> > > > > > [image: ShapeBlue] <http://www.shapeblue.com> Paul Angus VP
> > > > > > Technology , ShapeBlue
> > > > > > d: *+44 203 617 0528 | s: +44 203 603 0540*
> > > > > > <+44%20203%20617%200528%20%7C%20s:%20+44%20203%20603%200540> | m:
> > > > > > *+44 7711 418784* <+44%207711%20418784>
> > > > > > e: *paul.an...@shapeblue.com | t: @cloudyangus*
> > > > > > <paul.an...@shapeblue.com%20%7C%20t:%20@cloudyangus> | w:
> > > > > > *www.shapeblue.com* <http://www.shapeblue.com>
> > > > > > a: 53 Chandos Place, Covent Garden London WC2N 4HS UK Shape Blue
> > > > > > Ltd is a company incorporated in England & Wales. ShapeBlue
> > > > > > Services India LLP is a company incorporated in India and is
> > > > > > operated
> > > > > under
> > > > > > license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda
> > > > > > is a company incorporated in Brasil and is operated under
> > > > > > license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company
> > > > > > registered by The Republic
> > > > of
> > > > > > South Africa and is traded under license from Shape Blue Ltd.
> > > > > > ShapeBlue
> > > > > is
> > > > > > a registered trademark.
> > > > > > This email and any attachments to it may be confidential and are
> > > > intended
> > > > > > solely for the use of the individual to whom it is addressed.
> > > > > > Any views
> > > > > or
> > > > > > opinions expressed are solely those of the author and do not
> > > > necessarily
> > > > > > represent those of Shape Blue Ltd or related companies. If you
> > > > > > are not
> > > > > the
> > > > > > intended recipient of this email, you must neither take any
> > > > > > action
> > > > based
> > > > > > upon its contents, nor copy or show it to anyone. Please contact
> > > > > > the
> > > > > sender
> > > > > > if you believe you have received this email in error.
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Pierre-Luc Dion [mailto:pd...@cloudops.com]
> > > > > > Sent: Friday, February 5, 2016 12:56 PM
> > > > > > To: dev@cloudstack.apache.org
> > > > > > Subject: Re: [Propose][New Feature] Storage Snapshots
> > > > > >
> > > > > > Hi Mike,
> > > > > >
> > > > > > The idea of introducing a new API: StorageSnapshot for managed
> > > > > > storage
> > > > is
> > > > > > because the VolumeSnapshot default, or expected, behavior is to
> > > > > > archive snapshots into the Secondary Storage. So a
> > > > > > StorageSnapshot API would be
> > > > > for
> > > > > > snapshot that remain on the managed storage appliance.
> > > > > >
> > > > > > Quickly looking at the API doc and I don't see a strong
> > > > > > requirement for volume snapshots to be moved into secondary
> > > > > > storage. So, maybe StorageSnapshot API is not useful, but both
> > > > > > use cases are required. A snapshot that remain on the managed
> > > > > > storage, and another type of
> > > > snapshot
> > > > > > that end up into the secondary storage. Since you've done a lot
> > > > > > of
> > > > work,
> > > > > > might easier to just add a parameter to the current snapshot API
> > > > > > that
> > > > > would
> > > > > > trigger an extraction of the storage snapshot into the secondary
> > > > storage?
> > > > > >
> > > > > > PL
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Feb 4, 2016 at 9:02 PM, Mike Tutkowski <
> > > > > > mike.tutkow...@solidfire.com
> > > > > > > wrote:
> > > > > >
> > > > > > > I think that all sounds reasonable then - thanks!
> > > > > > >
> > > > > > > On Thu, Feb 4, 2016 at 6:52 PM, Syed Mushtaq <
> > > > syed1.mush...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > >> You are correct Mike in terms of the requirements. One of our
> > > > earlier
> > > > > > >> iterations on this was to have an argument to the create
> > > > > > >> snapshot
> > > > API
> > > > > > >> which decides whether to backup the volume to sec storage but
> > > > > > >> we realized it would make management of snapshots quite messy
> > > > > > >> so we proposed a new api instead.
> > > > > > >>
> > > > > > >> On Thu, Feb 4, 2016, 8:29 PM Mike Tutkowski
> > > > > > >> <mike.tutkow...@solidfire.com>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >>> Hi,
> > > > > > >>>
> > > > > > >>> Just to make sure I understand all the requirements here:
> > > > > > >>>
> > > > > > >>> 1) This relates only to managed storage (1:1 mapping between
> > > > > > >>> a virtual disk and a backend SAN volume).
> > > > > > >>>
> > > > > > >>> 2) We want to take the current (introduced in 4.6)
> > > > > > >>> functionality, which creates a snapshot on the SAN, and
> > > > > > >>> extend it via a config option (or
> > > > > > >>> something) to not only take the SAN snapshot, but to copy
> > > > > > >>> the underlying VHD (XenServer only) to NFS.
> > > > > > >>>
> > > > > > >>> 3) The SAN snapshot is always taken. It's the backup to NFS
> > > > > > >>> that is optional.
> > > > > > >>>
> > > > > > >>> 4) Templates can be created from the snapshot that's on the
> > > > > > >>> SAN (already works).
> > > > > > >>>
> > > > > > >>> 5) CloudStack volumes can be created from the snapshot
> > > > > > >>> that's on
> > > > the
> > > > > > >>> SAN (already works as long as the new CloudStack volume ends
> > > > > > >>> up on the same primary storage).
> > > > > > >>>
> > > > > > >>> Would we have a need for a storage snapshot API then or
> > > > > > >>> would that just be the standard volume snapshot without the
> > > > > > >>> backup to
> > > NFS?
> > > > > > >>>
> > > > > > >>> Thanks!
> > > > > > >>> Mike
> > > > > > >>>
> > > > > > >>> On Thu, Feb 4, 2016 at 5:24 PM, Syed Mushtaq
> > > > > > >>> <syed1.mush...@gmail.com>
> > > > > > >>> wrote:
> > > > > > >>>
> > > > > > >>>> Is it possible to have both functionalities (snapshot on
> > > > > > >>>> SAN & Sec
> > > > > > >>>> Storage) coexist? Because Ideally, we would like to have
> both.
> > > > > > >>>> For example, some of our customers want to implement their
> > > > > > >>>> own backup strategies and do encryption to their backups
> > > > > > >>>> which is a perfect use case for Storage Snapshot while our
> > > > > > >>>> other customers will still keep using the standard volume
> > > snapshot.
> > > > > > >>>>
> > > > > > >>>> To keep things backward compatible, we can add a setting
> > > > > > >>>> which
> > > > says
> > > > > > >>>> to not upload on secondary storage, because, after all, you
> > > > > > >>>> would take a SAN snapshot first when doing a Volume
> Snapshot.
> > > > > > >>>> You could stop the process there and not do the upload.
> > > > > > >>>>
> > > > > > >>>> What do you think about this approach?
> > > > > > >>>>
> > > > > > >>>> Thanks,
> > > > > > >>>> -Syed
> > > > > > >>>>
> > > > > > >>>> On Thu, Feb 4, 2016 at 4:25 PM, Mike Tutkowski <
> > > > > > >>>> mike.tutkow...@solidfire.com> wrote:
> > > > > > >>>>
> > > > > > >>>>> So, this is just me thinking out load here, but if a given
> > > > > > >>>>> CloudStack cloud doesn't actually need to provide both the
> > > > ability
> > > > > > >>>>> to take a SAN snapshot and export it to NFS (if just
> > > > > > >>>>> taking a SAN snapshot is OK), then we might be able to get
> > > > > > >>>>> away with no new
> > > > API
> > > > > > >>>>> calls and simply implement a new custom snapshot strategy
> > > > > > >>>>> and
> > > > data
> > > > > > >>>>> motion strategy to handle the case where the CloudStack
> > > > > > >>>>> cloud
> > > > does
> > > > > > >>>>> want both a SAN snapshot and exported-to-NFS backup.
> > > > > > >>>>>
> > > > > > >>>>> In other words, the "default" behavior would be to use the
> > > > > > >>>>> snapshot strategy and data motion strategy that we already
> > > > > > >>>>> have (the one that only takes a SAN snapshot).
> > > > > > >>>>>
> > > > > > >>>>> If your CloudStack cloud, however, wants to take a SAN
> > > > > > >>>>> snapshot and have the data exported to NFS, then we could
> > > > > > >>>>> have you manipulate a Swing config file to make use of a
> > > > > > >>>>> new snapshot strategy and data motion strategy that
> > > > > > >>>>> performs both of these
> > > > > > activities.
> > > > > > >>>>>
> > > > > > >>>>> This way, the old behavior is still the default for users,
> > > > > > >>>>> but CloudStack admins can change this behavior via
> > > configuration.
> > > > > > >>>>>
> > > > > > >>>>> Thoughts?
> > > > > > >>>>>
> > > > > > >>>>> On Thu, Feb 4, 2016 at 11:55 AM, Mike Tutkowski <
> > > > > > >>>>> mike.tutkow...@solidfire.com> wrote:
> > > > > > >>>>>
> > > > > > >>>>>> Right...I think we will need to come up with a viable
> > > > > > >>>>>> upgrade path or some reasonable way for them to move from
> > > > > > >>>>>> the old way to the new way (and some obvious way that
> > > > > > >>>>>> they will know they need
> > > > to
> > > > > > do this).
> > > > > > >>>>>>
> > > > > > >>>>>> On Thu, Feb 4, 2016 at 11:45 AM, Syed Mushtaq <
> > > > > > >>>>>> syed1.mush...@gmail.com> wrote:
> > > > > > >>>>>>
> > > > > > >>>>>>> I'm not really sure about the upgrade path however,
> > > > > > >>>>>>> customers who are using 4.6 and are on a managed storage
> > > > > > >>>>>>> would no longer have the same functionality with Volume
> > > Snapshots.
> > > > > > >>>>>>>
> > > > > > >>>>>>> On Thu, Feb 4, 2016 at 1:43 PM, Syed Mushtaq <
> > > > > > >>>>>>> syed1.mush...@gmail.com> wrote:
> > > > > > >>>>>>>
> > > > > > >>>>>>>> So if I understand correctly, currently taking a Volume
> > > > > > >>>>>>>> Snapshots of a volume on a managed storage keeps it on
> > > > > > >>>>>>>> the storage array. As a part of this feature, we can
> > > > > > >>>>>>>> make sure
> > > > that
> > > > > > >>>>>>>> Volume Snapshots on managed storage are uploaded to the
> > > > > > >>>>>>>> secondary storage. This would make the Volume Snapshot
> > > > > > >>>>>>>> feature behave the same regardless of the storage
> > > > > > >>>>>>>> (managed or
> > > > > > >>>>>>>> non-managed) And, for utilizing the efficient backend
> > > > > > >>>>>>>> storage
> > > > > > capabilities, we can use the new storage snapshots API.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> On Thu, Feb 4, 2016 at 1:36 PM, Mike Tutkowski <
> > > > > > >>>>>>>> mike.tutkow...@solidfire.com> wrote:
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> Hi everyone,
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Whatever we do here, we need to have a plan to deal
> > > > > > >>>>>>>>> with the fact that we already have a feature (in 4.6
> > > > > > >>>>>>>>> and
> > > > > > >>>>>>>>> later) that allows you to use the existing
> > > > > > >>>>>>>>> volume-snapshot APIs to create a volume snapshot (for
> > > > > > >>>>>>>>> managed
> > > > > > >>>>>>>>> storage) that resides on a backend SAN (using a custom
> > > > > > >>>>>>>>> snapshot strategy and a custom data motion strategy).
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> If these new APIs go in, then how should the original
> > > > > > >>>>>>>>> implementation (present in 4.6 and later) be changed?
> > > > > > >>>>>>>>> If it
> > > > is
> > > > > > >>>>>>>>> changed, how do we support customers who are already
> > > > > > >>>>>>>>> using
> > > > the
> > > > > > >>>>>>>>> original volume-snapshot API to take snapshots on a
> > > > > > >>>>>>>>> backend
> > > > > SAN?
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Thanks,
> > > > > > >>>>>>>>> Mike
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> On Thu, Feb 4, 2016 at 11:27 AM, Will Stevens <
> > > > > > >>>>>>>>> wstev...@cloudops.com> wrote:
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> Will you be able to create a Template from a
> > > > StorageSnapshot?
> > > > > > >>>>>>>>>> If yes, will the template be stored in the secondary
> > > > > > >>>>>>>>>> storage like normal templates or will that be handled
> > > > > > >>>>>>>>>> somehow on the
> > > > > > vendor side?
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> *Will STEVENS*
> > > > > > >>>>>>>>>> Lead Developer
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> *CloudOps* *| *Cloud Solutions Experts
> > > > > > >>>>>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w
> > > > > > >>>>>>>>>> cloudops.com *|* tw @CloudOps_
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> On Thu, Feb 4, 2016 at 1:22 PM, Syed Mushtaq <
> > > > > > >>>>>>>>>> syed1.mush...@gmail.com> wrote:
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>> Thanks Will!!!
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> On Thu, Feb 4, 2016 at 1:19 PM, Will Stevens <
> > > > > > >>>>>>>>>>> wstev...@cloudops.com> wrote:
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>> I explicitly linked the Design Spec in the Jira
> > > > > > >>>>>>>>>>>> ticket because it was not clear in the 'mention'
> > > > > > >>>>>>>>>>>> section because it shows as a page 'you do not have
> > > permission to'.
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> *Will STEVENS*
> > > > > > >>>>>>>>>>>> Lead Developer
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> *CloudOps* *| *Cloud Solutions Experts
> > > > > > >>>>>>>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w
> > > > > > >>>>>>>>>>>> cloudops.com *|* tw @CloudOps_
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> On Thu, Feb 4, 2016 at 1:02 PM, Syed Ahmed
> > > > > > >>>>>>>>>>>> <sah...@cloudops.com
> > > > > > >>>>>>>>>>>> > wrote:
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> Design Spec:
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>
> > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Sto
> > > > > > >>>>>>>>>>>>> rageSnapshot++API
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> Jira Ticket
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-9
> > > > > > >>>>>>>>>>>>> 27
> > > > > > >>>>>>>>>>>>> 8
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> Hi All,
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> We plan to propose a new set of APIs to do
> > > > > > >>>>>>>>>>>>> snapshots on managed storage backends like
> SolidFire.
> > > > > > >>>>>>>>>>>>> Snapshots on current managed storage stay on the
> > > > > > >>>>>>>>>>>>> device which is contrary to what CloudStack calls
> > > snpshots.
> > > > > > >>>>>>>>>>>>> But taking snapshots on storage and keeping it
> > > > > > >>>>>>>>>>>>> there has its own advantages
> > > > and
> > > > > > >>>>>>>>>>>>> we would ideally like to have both ways of doing
> > > > > > >>>>>>>>>>>>> snapshots. This proposal adds 4 new APIs to create
> > > > > > >>>>>>>>>>>>> snapshots on backend storage.
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> What do you guys think of this feature? I would
> > > > > > >>>>>>>>>>>>> love to have some feedback. I am working on making
> > > > > > >>>>>>>>>>>>> the design
> > > > spec
> > > > > > >>>>>>>>>>>>> more concrete but wanted to have a high level
> > > > > > >>>>>>>>>>>>> feedback first before starting to work on it.
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>> Thanks,
> > > > > > >>>>>>>>>>>>> -Syed
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>>
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> --
> > > > > > >>>>>>>>> *Mike Tutkowski*
> > > > > > >>>>>>>>> *Senior CloudStack Developer, SolidFire Inc.*
> > > > > > >>>>>>>>> e: mike.tutkow...@solidfire.com
> > > > > > >>>>>>>>> o: 303.746.7302
> > > > > > >>>>>>>>> Advancing the way the world uses the cloud
> > > > > > >>>>>>>>> <http://solidfire.com/solution/overview/?video=play>*™
> > > > > > >>>>>>>>> *
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>> --
> > > > > > >>>>>> *Mike Tutkowski*
> > > > > > >>>>>> *Senior CloudStack Developer, SolidFire Inc.*
> > > > > > >>>>>> e: mike.tutkow...@solidfire.com
> > > > > > >>>>>> o: 303.746.7302
> > > > > > >>>>>> Advancing the way the world uses the cloud
> > > > > > >>>>>> <http://solidfire.com/solution/overview/?video=play>*™*
> > > > > > >>>>>>
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>> --
> > > > > > >>>>> *Mike Tutkowski*
> > > > > > >>>>> *Senior CloudStack Developer, SolidFire Inc.*
> > > > > > >>>>> e: mike.tutkow...@solidfire.com
> > > > > > >>>>> o: 303.746.7302
> > > > > > >>>>> Advancing the way the world uses the cloud
> > > > > > >>>>> <http://solidfire.com/solution/overview/?video=play>*™*
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> --
> > > > > > >>> *Mike Tutkowski*
> > > > > > >>> *Senior CloudStack Developer, SolidFire Inc.*
> > > > > > >>> e: mike.tutkow...@solidfire.com
> > > > > > >>> o: 303.746.7302
> > > > > > >>> Advancing the way the world uses the cloud
> > > > > > >>> <http://solidfire.com/solution/overview/?video=play>*™*
> > > > > > >>>
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > *Mike Tutkowski*
> > > > > > > *Senior CloudStack Developer, SolidFire Inc.*
> > > > > > > e: mike.tutkow...@solidfire.com
> > > > > > > o: 303.746.7302
> > > > > > > Advancing the way the world uses the cloud
> > > > > > > <http://solidfire.com/solution/overview/?video=play>*™*
> > > > > > >
> > > > > > Find out more about ShapeBlue and our range of CloudStack
> > > > > > related
> > > > > services:
> > > > > > IaaS Cloud Design & Build
> > > > > > <http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge –
> > > > > > rapid IaaS deployment framework <http://shapeblue.com/csforge/>
> > > > > > CloudStack Consulting
> > > > > > <http://shapeblue.com/cloudstack-consultancy/> |
> > > > > CloudStack
> > > > > > Software Engineering
> > > > > > <http://shapeblue.com/cloudstack-software-engineering/>
> > > > > > CloudStack Infrastructure Support
> > > > > > <http://shapeblue.com/cloudstack-infrastructure-support/> |
> > > > > > CloudStack Bootcamp Training Courses
> > > > > > <http://shapeblue.com/cloudstack-training/>
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > *Mike Tutkowski*
> > > > *Senior CloudStack Developer, SolidFire Inc.*
> > > > e: mike.tutkow...@solidfire.com
> > > > o: 303.746.7302
> > > > Advancing the way the world uses the cloud
> > > > <http://solidfire.com/solution/overview/?video=play>*™*
> > > >
> > > Find out more about ShapeBlue and our range of CloudStack related
> > services:
> > > IaaS Cloud Design & Build
> > > <http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid
> > > IaaS deployment framework <http://shapeblue.com/csforge/> CloudStack
> > > Consulting <http://shapeblue.com/cloudstack-consultancy/> | CloudStack
> > > Software Engineering
> > > <http://shapeblue.com/cloudstack-software-engineering/>
> > > CloudStack Infrastructure Support
> > > <http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack
> > > Bootcamp Training Courses <http://shapeblue.com/cloudstack-training/>
> > >
> > Find out more about ShapeBlue and our range of CloudStack related
> services:
> > IaaS Cloud Design & Build
> > <http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid
> > IaaS deployment framework <http://shapeblue.com/csforge/>
> > CloudStack Consulting <http://shapeblue.com/cloudstack-consultancy/> |
> CloudStack
> > Software Engineering
> > <http://shapeblue.com/cloudstack-software-engineering/>
> > CloudStack Infrastructure Support
> > <http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack
> > Bootcamp Training Courses <http://shapeblue.com/cloudstack-training/>
> >
>
