[openstack-dev] [Cinder][Driver] Delete snapshot

John Griffith john.griffith at solidfire.com
Thu Jun 19 17:17:06 UTC 2014


On Thu, Jun 19, 2014 at 11:01 AM, Amit Das <amit.das at cloudbyte.com> wrote:

> Hi All,
>
> Thanks for clarifying the Cinder behavior w.r.t a snapshot & its clones
> which seems to be independent/decoupled.
> The current volume & its snapshot based validations in Cinder holds true
> for snapshot & its clones w.r.t my storage requirements.
>
> Our storage is built on top of ZFS filesystem.
>
​Ahh.. yes, we've had similar discussions with Nexenta and other ZFS
derivatives on this.

The only thing I've thought of here is the use of some trickery in the form
of "hidden/system" objects.  It creates a bit of a quota nightmare and
admin mess though.  Maybe we can get all the ZFS folks (and I believe Ceph
has some similar capabilities here) and come up with a solution that
doesn't break the API behaviors.
​

> The volume -> snapshot -> clone that I am referring to in turn points to a
> ZFS dataset -> ZFS snapshot -> ZFS clone.
>
> The best part of ZFS based snapshots & clones are :
>
>    - these are almost instantaneous ( i.e. copy-on-write based copies)
>    - these will not consume any additional (initially)
>       - a clone initially shares all its disk space with the original
>       snapshot, its used property is initially zero.
>       - As changes are made to the clone, it uses more space.
>       - The used property of the original snapshot does not consider the
>       disk space consumed by the clone.
>
> Further optimizations i.e. cool feature:
>
>    - While creating VM clones, a hypervisor driver can delegate part of
>    its cloning process to storage driver & hence, the overall VM cloning will
>    be very very fast.
>
>
>
>
> Regards,
> Amit
> *CloudByte Inc.* <http://www.cloudbyte.com/>
>
>
> On Thu, Jun 19, 2014 at 9:16 PM, John Griffith <
> john.griffith at solidfire.com> wrote:
>
>>
>>
>>
>> On Tue, Jun 17, 2014 at 10:50 PM, Amit Das <amit.das at cloudbyte.com>
>> wrote:
>>
>>> Hi Stackers,
>>>
>>> I have been implementing a Cinder driver for our storage solution &
>>> facing issues with below scenario.
>>>
>>> Scenario - When a user/admin tries to delete a snapshot that has
>>> associated clone(s), an error message/log should be shown to the user
>>> stating that '*There are clones associated to this snapshot. Hence,
>>> snapshot cannot be deleted*'.
>>>
>>
>> ​What's the use model of "clones associated with the snapshot"?  What are
>> these "clones" from a Cinder perspective.  Easy answer is: don't create
>> them, but I realize you probably have a cool feature or optimization that
>> you're trying to leverage here.​
>>
>>>
>>> Implementation issues - If Cinder driver throws an Exception the
>>> snapshot will have error_deleting status & will not be usable. If Cinder
>>> driver logs the error silently then Openstack will probably mark the
>>> snapshot as deleted.
>>>
>>
>> ​So as others point out, from a Cinder perspective this is what I/we
>> would expect.
>>
>> Scott made some really good points, but the point is we do not want to
>> behave differently for every single driver.  The agreed upon mission for
>> Cinder is to actually provide a consistent API and set of behaviors to end
>> users regardless of what backend device they're using (in other words that
>> should remain pretty much invisible to the end-user).
>>
>> What do you use the Clones of the Snapshot for?  Maybe we can come up
>> with another approach that works and keeps consistency in the API.
>>
>>
>>
>>> What is the appropriate procedure that needs to be followed for above
>>> usecase.
>>>
>>> Regards,
>>> Amit
>>> *CloudByte Inc.* <http://www.cloudbyte.com/>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140619/2ef19aac/attachment.html>


More information about the OpenStack-dev mailing list