[nova] Updates about Detaching/Attaching root volumes

Matt Riedemann mriedemos at gmail.com
Fri Mar 1 00:24:08 UTC 2019

On 2/28/2019 6:02 PM, Dan Smith wrote:
> So, IMHO, we should select a path that does not make the user choose
> between the "tags or detach" dichotomy above. Some options for that are:

I've got a few questions for clarification below.

> 1. Don't wipe the tag on detach. On re-attach, let them specify a tag if
> there is already one set on the BDM. Clearly that means tags were
> supported before, so a reasonable guess that they still are.
> 2. Specifically for the above case, either (a) require they pass in the
> tag they want on the new volume if they want to keep/change it or (b)
> assume it stays the same unless they specify a null tag to remove it.

Is this (a) *or* (b)? If I create a server with a device tag on the root 
bdm, then detach the root volume and am happy with the tag that was 
there, so on attach of a new root volume I don't specify a new tag - do 
I lose it because I didn't specify the same tag over again? I would 
expect that if I had a tag, I can keep it without specifying anything 
different, or change it by specifying some new (new tag or null it out). 
If I didn't have a tag on the root bdm when I detached, I can't specify 
a new one because we don't know if we can honor it (existing behavior 
for attaching volumes to shelved instances). Does what I just described 
equate to option 1 above? If so, then I'd vote for option 1 here.

> 3. Always let them specify a tag on attach, and if that means they're
> not un-shelve-able because no compute nodes support tags, then that's
> the same case as if you show up with tag-having boot request. Let them
> de-and-re-attach the volume to wipe the tag and then unshelve.

So this is option 4 but fail the unshelve if the compute driver they 
land on doesn't support tags, thus making it more restrictive than 
option 4. I'm not crazy about this one because if we just start checking 
device tags on unshelve always we will arguably change behavior - 
granted the behavior we have today is you get lucky and land on a host 
that supports tags (this is not an unreasonable assumption if you are 
using a cloud with homogeneous virt drivers which I expect most do) or 
you land on a host that doesn't and we don't honor the tags, so sorry.

> 4. Always let them specify a tag on attach and just not freak out on
> unshelve if we end up picking a host with no tag support.

This was essentially my first option:

"1: lift the restriction in this same microversion so that you can 
attach volumes to a shelved offloaded server and specify a tag (despite 
bug 1817927 which we can fix later)"




More information about the openstack-discuss mailing list