<div dir="ltr">A silly method could be add a new param "cleanup_original_tag" and it could only be provided if "is_root"=True and no new tag provided. So when<div>cleanup_original_tag=True or the user provided a new tag, we cleanup/update the old tag, otherwise we keep it.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 1, 2019 at 10:36 AM Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/28/2019 7:54 PM, Zhenyu Zheng wrote:<br>
> Thanks alot for all the suggestions, so as a summary:<br>
> 1. do not wipe out the tag when detach<br>
> 2. free the limit on do not allow attach volume with tag for <br>
> shelved_offloaded instance if it is a root volume(we can check whether <br>
> ``is_root`` is True)<br>
>      2a. if user does not provide any tag, we keep the old tag<br>
>      2b. if user provide a new tag, we update the new tag<br>
>      2c. provide a way for user to indicate that I want to null out the <br>
> previous tag<br>
> <br>
> is my understanding correct?<br>
<br>
I think so. For 2c, that gets complicated because the schema for the tag <br>
is not nullable [1][2]. So then you're left with leave it or overwrite <br>
the tag you had, but you can't go from no tag to tag or vice-versa <br>
(without a schema change....).<br>
<br>
Also one final note here, but multiattach volumes are in the same <br>
conundrum, meaning they aren't allowed to attach to a shelved offloaded <br>
instance, but if we draw on Dan's use case, picking between detaching a <br>
root volume and not being able to attach another multiattach root <br>
volume, isn't a good option. So if we're going to do this for tags, I <br>
think we ought to do it for multiattach volumes as well. In other words, <br>
if the root volume was multiattach before it was detached, then the new <br>
root volume can be multiattach, but you can't go from non-multiattach to <br>
multiattach while shelved offloaded. The crappy thing about multiattach <br>
is it's not a clear attribute on the BDM object, it's buried in the <br>
BDM.connection_info [3], but we can still sort that out with a helper <br>
method (but it means you can't reset the connection_info when detaching <br>
the root volume).<br>
<br>
[1] <br>
<a href="https://github.com/openstack/nova/blob/a8c065dea946599a1b07d003cd21409c4cd58df0/nova/api/openstack/compute/schemas/volumes.py#L88" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/a8c065dea946599a1b07d003cd21409c4cd58df0/nova/api/openstack/compute/schemas/volumes.py#L88</a><br>
[2] <br>
<a href="https://github.com/openstack/nova/blob/a8c065dea946599a1b07d003cd21409c4cd58df0/nova/api/validation/parameter_types.py#L498" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/a8c065dea946599a1b07d003cd21409c4cd58df0/nova/api/validation/parameter_types.py#L498</a><br>
[3] <br>
<a href="https://github.com/openstack/nova/blob/a8c065dea946599a1b07d003cd21409c4cd58df0/nova/virt/block_device.py#L549" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/a8c065dea946599a1b07d003cd21409c4cd58df0/nova/virt/block_device.py#L549</a><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
</blockquote></div>