Open Stack

On 2/26/2019 7:21 AM, Matt Riedemann wrote:
> Yeah I am not sure what to do here. Here is a scenario:
> 
> User boots from volume with a tag "ubuntu1604vol" to indicate it's the 
> root volume with the operating system. Then they shelve offload the 
> server and detach the root volume. At this point, the GET 
> /servers/{server_id}/os-volume_attachments API is going to show None for 
> the volume_id on that BDM but should it show the original tag or also 
> show None for that. Kevin currently has the tag field being reset to 
> None when the root volume is detached.
> 
> When the user attaches a new root volume, they can provide a new tag so 
> even if we did not reset the tag, the user can overwrite it. As a user, 
> would you expect the tag to be reset when the root volume is detached or 
> have it persist but be overwritable?
> 
> If in this scenario the user then attaches a new root volume that is 
> CentOS or Ubuntu 18.04 or something like that, but forgets to update the 
> tag, then the old tag would be misleading.
> 
> So it is probably safest to just reset the tag like Kevin's proposed 
> code is doing, but we could use some wider feedback here.

I just realized that the user providing a new tag when attaching the new 
root volume won't work, because we are only going to allow attaching a 
new root volume to a shelved offloaded instance, which explicitly 
rejects providing a tag in that case [1].

So we likely need to lift that restriction in this microversion and then 
on unshelve in the compute service we need to check if the compute 
supports device tags like during server create and if not, the unshelve 
will fail. Now that I think about that, that's likely already a bug 
today, i.e. if I create a server with device tags at server create time 
and land on a host that supports them, but then shelve offload and 
unshelve to a compute that does not support them, the unshelve won't 
fail even though the compute doesn't support the device tags on my 
attached volumes/ports.

[1] https://review.openstack.org/#/c/623981/18/nova/compute/api.py@4264

-- 

Thanks,

Matt