<div dir="ltr">Thanks alot for all the suggestions, so as a summary:<div>1. do not wipe out the tag when detach</div><div>2. free the limit on do not allow attach volume with tag for shelved_offloaded instance if it is a root volume(we can check whether ``is_root`` is True)</div><div>    2a. if user does not provide any tag, we keep the old tag</div><div>    2b. if user provide a new tag, we update the new tag</div><div>    2c. provide a way for user to indicate that I want to null out the previous tag</div><div><br></div><div>is my understanding correct?</div><div><br></div><div>BR, </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 1, 2019 at 8:32 AM Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.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">>> 1. Don't wipe the tag on detach. On re-attach, let them specify a tag if<br>
>> there is already one set on the BDM. Clearly that means tags were<br>
>> supported before, so a reasonable guess that they still are.<br>
>><br>
>> 2. Specifically for the above case, either (a) require they pass in the<br>
>> tag they want on the new volume if they want to keep/change it or (b)<br>
>> assume it stays the same unless they specify a null tag to remove it.<br>
><br>
> Is this (a) *or* (b)?<br>
<br>
Yes because it describes complementary behaviors.<br>
<br>
> If I create a server with a device tag on the root bdm, then detach<br>
> the root volume and am happy with the tag that was there, so on attach<br>
> of a new root volume I don't specify a new tag - do I lose it because<br>
> I didn't specify the same tag over again? I would expect that if I had<br>
> a tag, I can keep it without specifying anything different, or change<br>
> it by specifying some new (new tag or null it out). If I didn't have a<br>
> tag on the root bdm when I detached, I can't specify a new one because<br>
> we don't know if we can honor it (existing behavior for attaching<br>
> volumes to shelved instances). Does what I just described equate to<br>
> option 1 above? If so, then I'd vote for option 1 here.<br>
<br>
No, what you describe is 2b and that's fine with me. Maybe I should<br>
check my outline style, but 1 is the general idea, 2a and 2b are each<br>
behaviors we'd choose from when implementing 1.<br>
<br>
>> 3. Always let them specify a tag on attach, and if that means they're<br>
>> not un-shelve-able because no compute nodes support tags, then that's<br>
>> the same case as if you show up with tag-having boot request. Let them<br>
>> de-and-re-attach the volume to wipe the tag and then unshelve.<br>
><br>
> So this is option 4 but fail the unshelve if the compute driver they<br>
> land on doesn't support tags, thus making it more restrictive than<br>
> option 4. I'm not crazy about this one because if we just start<br>
> checking device tags on unshelve always we will arguably change<br>
> behavior - <br>
> granted the behavior we have today is you get lucky and land on a host<br>
> that supports tags (this is not an unreasonable assumption if you are<br>
> using a cloud with homogeneous virt drivers which I expect most do) or<br>
> you land on a host that doesn't and we don't honor the tags, so sorry.<br>
<br>
Sure, that's fine. it seems like the most obvious option to me, but if<br>
it means we'd be tweaking existing behavior, then it makes sense to<br>
avoid it.<br>
<br>
--Dan<br>
</blockquote></div>