Re: [openstack-dev] [cinder] Why not allow deleting volume from a CG ?
On 16:34 Mon 09 Feb , Nilesh P Bhosale wrote: 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? Xing and I have already explained the reasons for this decision previously in the thread. Besides it being an accident, you're making an assumption that all backends will handle directly removing a volume from a consistency group the same. I see a few ways they can handle it: 1) The backend errors on this, and the end user will never see the error, because it just goes to Cinder logs from the Cinder volume service. 2) The backend allows it, but they still see that volume part of the consistency group, even if it was deleted. Leaving things in a weird state. 3) The backend allows the delete and updates the consistency group accordingly. With 72 different drivers, you can't make an assumption here. 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. Can you explain more how this is expensive? I would argue making a mistake in deleting a volume that's part of a consistency group on accident would be an expensive mistake. In fact, I think whatever decision user takes, even to delete a normal volume, is treated as his conscious decision. We're humans, we make mistakes. I work on an interface that assumes this. -- 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
Re: [openstack-dev] [cinder] Why not allow deleting volume from a CG ?
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
Re: [openstack-dev] [cinder] Why not allow deleting volume from a CG ?
On 9 February 2015 at 13:04, Nilesh P Bhosale nilesh.bhos...@in.ibm.com wrote: 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? Because the risk of a user accidentally deleting a volume that is part of a CG and making their CG useless was considered greater than the cost of having to make two API calls. This was discussed during the design phase of CGs, at length. Many things are possible, be are trying to choose a subset that can be: - Implemented on as many different backends as possible - Don't limit backend architectures from doing novel new things - Allow a rich tenant experience - Guide a tenant away from operating in a high-risk manner -- Duncan Thomas __ 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
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
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
