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.y...@emc.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@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:thin...@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-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
__________________________________________________________________________ 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