Open Stack

On 1/2/2019 2:57 AM, Zhenyu Zheng wrote:
> I've been working on detach-boot-volume[1] in Stein, we got the initial 
> design merged and while implementing we have meet some new problems and 
> now I'm amending the spec to cover these new problems[2].

[2] is https://review.openstack.org/#/c/619161/

> 
> The thing I want to discuss for wider opinion is that in the initial 
> design, we planned to support detach root volume for only STOPPED and 
> SHELVED/SHELVE_OFFLOADED instances. But then we found out that we 
> allowed to detach volumes for RESIZED/PAUSED/SOFT_DELETED instances as 
> well. Should we allow detaching root volume for instances in these 
> status too? Cases like RESIZE could be complicated for the revert resize 
> action, and it also seems unnecesary.

The full set of allowed states for attaching and detaching are here:

https://github.com/openstack/nova/blob/8ef3d253a/nova/compute/api.py#L4187

https://github.com/openstack/nova/blob/8ef3d253a/nova/compute/api.py#L4297

Concerning those other states:

RESIZED: There might be a case for attaching/detaching volumes based on 
flavor during a resize, but I'm not sure about the root volume in that 
case (that really sounds more like rebuild with a new image to me, which 
is a different blueprint). I'm also not sure how much people know about 
the ability to do this or what the behavior is on revert if you have 
changed the volumes while the server is resized. If we consider that 
when a user reverts a resize, they want to go back to the way things 
were for the root disk image, then I would think we should not allow 
changing out the root volume while resized.

PAUSED: First, I'm not sure how much anyone uses the pause API (or 
suspend for that matter) although most of the virt drivers implement it. 
At one point you could attach volumes to suspended servers as well, but 
because libvirt didn't support it that was removed from the API (yay for 
non-discoverable backend-specific API behavior changes):

https://review.openstack.org/#/c/83505/

Anyway, swapping the root volume on a paused instance seems dangerous to 
me, so until someone really has a good use case for it, then I think we 
should avoid that one as well.

SOFT_DELETED: I really don't understand the use case for 
attaching/detaching volumes to/from a (soft) deleted server. If the 
server is deleted and only hanging around because it hasn't been 
reclaimed yet, there are really no guarantees that this would work, so 
again, I would just skip this one for the root volume changes. If the 
user really wants to play with the volumes attached to a soft deleted 
server, they should restore it first.

So in summary, I think we should just not support any of those other 
states for attach/detach root volumes and only focus on stopped or 
shelved instances.

-- 

Thanks,

Matt