<div dir="ltr">This is what I thought of as well.  In the rbd driver, if a request to delete a volume comes in, where the volume object on the backend has other objects that depend on it, it simply renames it:<div><a href="https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/rbd.py#L657">https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/rbd.py#L657</a><br>
</div><div><br></div><div>There is also code to clean up those renamed objects.</div><div><br></div><div>The point is, Cinder has an API which should be consistent no matter what storage is being used.  The driver must do whatever necessary to implement the API rather than allowing quirks of the specific storage to show through to the user.</div>
<div><br></div><div>Thanks,</div><div>Avishay</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 19, 2014 at 8:13 PM, Duncan Thomas <span dir="ltr"><<a href="mailto:duncan.thomas@gmail.com" target="_blank">duncan.thomas@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So these are all features that various other backends manage to<br>
implement successfully.<br>
<br>
Your best point of reference might be the ceph code - I believe it<br>
deals with very similar issues in various ways.<br>
<div><div class="h5"><br>
On 19 June 2014 18:01, Amit Das <<a href="mailto:amit.das@cloudbyte.com">amit.das@cloudbyte.com</a>> wrote:<br>
> Hi All,<br>
><br>
> Thanks for clarifying the Cinder behavior w.r.t a snapshot & its clones<br>
> which seems to be independent/decoupled.<br>
> The current volume & its snapshot based validations in Cinder holds true for<br>
> snapshot & its clones w.r.t my storage requirements.<br>
><br>
> Our storage is built on top of ZFS filesystem.<br>
> The volume -> snapshot -> clone that I am referring to in turn points to a<br>
> ZFS dataset -> ZFS snapshot -> ZFS clone.<br>
><br>
> The best part of ZFS based snapshots & clones are :<br>
><br>
> these are almost instantaneous ( i.e. copy-on-write based copies)<br>
> these will not consume any additional (initially)<br>
><br>
> a clone initially shares all its disk space with the original snapshot, its<br>
> used property is initially zero.<br>
> As changes are made to the clone, it uses more space.<br>
> The used property of the original snapshot does not consider the disk space<br>
> consumed by the clone.<br>
><br>
> Further optimizations i.e. cool feature:<br>
><br>
> While creating VM clones, a hypervisor driver can delegate part of its<br>
> cloning process to storage driver & hence, the overall VM cloning will be<br>
> very very fast.<br>
><br>
><br>
><br>
><br>
> Regards,<br>
> Amit<br>
> CloudByte Inc.<br>
><br>
><br>
> On Thu, Jun 19, 2014 at 9:16 PM, John Griffith <<a href="mailto:john.griffith@solidfire.com">john.griffith@solidfire.com</a>><br>
> wrote:<br>
>><br>
>><br>
>><br>
>><br>
>> On Tue, Jun 17, 2014 at 10:50 PM, Amit Das <<a href="mailto:amit.das@cloudbyte.com">amit.das@cloudbyte.com</a>> wrote:<br>
>>><br>
>>> Hi Stackers,<br>
>>><br>
>>> I have been implementing a Cinder driver for our storage solution &<br>
>>> facing issues with below scenario.<br>
>>><br>
>>> Scenario - When a user/admin tries to delete a snapshot that has<br>
>>> associated clone(s), an error message/log should be shown to the user<br>
>>> stating that 'There are clones associated to this snapshot. Hence, snapshot<br>
>>> cannot be deleted'.<br>
>><br>
>><br>
>> What's the use model of "clones associated with the snapshot"?  What are<br>
>> these "clones" from a Cinder perspective.  Easy answer is: don't create<br>
>> them, but I realize you probably have a cool feature or optimization that<br>
>> you're trying to leverage here.<br>
>>><br>
>>><br>
</div></div><div class="">>>> Implementation issues - If Cinder driver throws an Exception the snapshot<br>
>>> will have error_deleting status & will not be usable. If Cinder driver logs<br>
>>> the error silently then Openstack will probably mark the snapshot as<br>
>>> deleted.<br>
>><br>
>><br>
</div>>> So as others point out, from a Cinder perspective this is what I/we would<br>
>> expect.<br>
>><br>
>> Scott made some really good points, but the point is we do not want to<br>
>> behave differently for every single driver.  The agreed upon mission for<br>
>> Cinder is to actually provide a consistent API and set of behaviors to end<br>
>> users regardless of what backend device they're using (in other words that<br>
>> should remain pretty much invisible to the end-user).<br>
>><br>
>> What do you use the Clones of the Snapshot for?  Maybe we can come up with<br>
>> another approach that works and keeps consistency in the API.<br>
<div class="">>><br>
>><br>
>>><br>
>>> What is the appropriate procedure that needs to be followed for above<br>
>>> usecase.<br>
>>><br>
</div>>>> Regards,<br>
>>> Amit<br>
>>> CloudByte Inc.<br>
<div class="HOEnZb"><div class="h5">>>><br>
>>> _______________________________________________<br>
>>> OpenStack-dev mailing list<br>
>>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
Duncan Thomas<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>