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