Open Stack

>> 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)?

Yes because it describes complementary behaviors.

> 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.

No, what you describe is 2b and that's fine with me. Maybe I should
check my outline style, but 1 is the general idea, 2a and 2b are each
behaviors we'd choose from when implementing 1.

>> 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.

Sure, that's fine. it seems like the most obvious option to me, but if
it means we'd be tweaking existing behavior, then it makes sense to
avoid it.

--Dan