Open Stack

On Tue, Dec 8, 2015 at 9:10 PM, Li, Xiaoyan <xiaoyan.li at intel.com> wrote:

> Hi all,
>
> Currently when deleting a volume, it checks whether there are snapshots
> created from it. If yes deletion is prohibited.  But it allows to extend
> the volume, no check whether there are snapshots from it.
>
​Correct​


>
> The two behaviors in Cinder are not consistent from my viewpoint.
>
​Well, your snapshot was taken at a point in time; and if you do a create
from snapshot the whole point is you want what you HAD when the snapshot
command was issued and NOT what happened afterwards.  So in my opinion this
is not inconsistent at all.
​


>
> In backend storage, their behaviors are same.
>
​Which backend storage are you referring to in this case?
​


> For full snapshot, if still in copying progress, both extend and deletion
> are not allowed. If snapshot copying finishes, both extend and deletion are
> allowed.
> For incremental snapshot, both extend and deletion are not allowed.
>

​So your particular backend has "different/specific" rules/requirements
around snapshots.  That's pretty common, I don't suppose theres any way to
hack around this internally?  In other words do things on your backend like
clones as snaps etc to make up for the differences in behavior?​


>
> As a result, this raises two concerns here:
> 1. Let such operations behavior same in Cinder.
> 2. I prefer to let storage driver decide the dependencies, not in the
> general core codes.
>

​I have and always will strongly disagree with this approach and your
proposal.  Sadly we've already started to allow more and more vendor
drivers just "do their own thing" and implement their own special API
methods.  This is in my opinion a horrible path and defeats the entire
purpose of have a Cinder abstraction layer.

This will make it impossible to have compatibility between clouds for those
that care about it, it will make it impossible for operators/deployers to
understand exactly what they can and should expect in terms of the usage of
their cloud.  Finally, it will also mean that not OpenStack API
functionality is COMPLETELY dependent on backend device.  I know people are
sick of hearing me say this, so I'll keep it short and say it one more time:
"Compatibility in the API matters and should always be our priority"


> Meanwhile, if we let driver to decide the dependencies, the following
> changes need to do in Cinder:
> 1. When creating a snapshot from volume, it needs copy all metadata of
> volume to snapshot. Currently it doesn't.
> Any other potential issues please let me know.
>
> Any input will be appreciated.
>
> Best wishes
> Lisa
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20151209/5942a823/attachment.html>