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