cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Syed Mushtaq <syed1.mush...@gmail.com>
Subject Re: [Propose][New Feature] Storage Snapshots
Date Thu, 04 Feb 2016 18:45:05 GMT
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.mushtaq@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.tutkowski@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 <wstevens@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.mushtaq@gmail.com>
>>> wrote:
>>>
>>>> Thanks Will!!!
>>>>
>>>> On Thu, Feb 4, 2016 at 1:19 PM, Will Stevens <wstevens@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 <sahmed@cloudops.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Design Spec:
>>>>>>
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/StorageSnapshot++API
>>>>>>
>>>>>> Jira Ticket
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/CLOUDSTACK-9278
>>>>>>
>>>>>>
>>>>>> 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.tutkowski@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the cloud
>> <http://solidfire.com/solution/overview/?video=play>*™*
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message