Open Stack

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