On Tue, Dec 8, 2015 at 9:10 PM, Li, Xiaoyan <xiaoyan...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
