Open Stack

Adding an ability to Add/Remove existing volumes to/from CG looks fine. 
But, it does not help the use-case where one would want to directly delete 
a volume from CG.
Why do we force him to first remove a volume from CG and then delete?
As CG goes along with replication and backends creating a separate pool 
per CG, removing a volume from CG, just to be able to delete it in the 
next step, may be an unnecessary expensive operation.

I think, we can allow removing volume from a CG with something like 
'--force' option, so that user consciously makes that decision.

In fact, I think whatever decision user takes, even to delete a normal 
volume, is treated as his conscious decision.

Thanks,
Nilesh



From:   "yang, xing" <xing.yang at emc.com>
To:     "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev at lists.openstack.org>
Date:   02/07/2015 01:54 AM
Subject:        Re: [openstack-dev] [cinder] Why not allow deleting volume 
from a CG ?



As Mike said, allowing deletion of a single volume from a CG is error 
prone.  User could be deleting a single volume without knowing that it is 
part of a CG.  The new Modify CG feature for Kilo allows you to remove a 
volume from CG and you can delete it as a separate operation.  When user 
removes a volume from a CG, at least he/she is making a conscious decision 
knowing that the volume is currently part of the CG.

Thanks,
Xing


-----Original Message-----
From: Mike Perez [mailto:thingee at gmail.com] 
Sent: Friday, February 06, 2015 1:47 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [cinder] Why not allow deleting volume from a 
CG ?

On 15:51 Fri 06 Feb     , Nilesh P Bhosale wrote:
<snip>
> I understand this is as per design, but curious to understand logic 
> behind this.
<snip>
> Why not allow deletion of volumes form the CG? at least when there are 
> no dependent snapshots.

>From the review [1], this is because allowing a volume that's part of a 
consistency group to be deleted is error prone for both the user and the 
storage backend. It assumes the storage backend will register the volume 
not being part of the consistency group. It also assumes the user is 
keeping tracking of what's part of a consistency group.

> With the current implementation, only way to delete the volume is to 
> delete the complete CG, deleting all the volumes in that, which I feel 
> is not right.

The plan in Kilo is to allow adding/removing volumes from a consistency 
group [2][3]. The user now has to explicitly remove the volume from a 
consistency group, which in my opinion is better than implicit with 
delete.

I'm open to rediscussing this issue with vendors and seeing about making 
sure things in the backend to be cleaned up properly, but I think this 
solution helps prevent the issue for both users and backends.

[1] - https://review.openstack.org/#/c/149095/
[2] - 
https://blueprints.launchpad.net/cinder/+spec/consistency-groups-kilo-update

[3] - https://review.openstack.org/#/c/144561/

--
Mike Perez

__________________________________________________________________________
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

__________________________________________________________________________
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/20150209/31df77bd/attachment.html>