[Nova] Suggestion needed for detach-boot-volume design
mriedemos at gmail.com
Fri Jan 4 15:50:46 UTC 2019
On 1/2/2019 2:57 AM, Zhenyu Zheng wrote:
> I've been working on detach-boot-volume 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.
 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:
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):
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
More information about the openstack-discuss