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)" -- Thanks, Matt