Open Stack

Thanks alot for all the suggestions, so as a summary:
1. do not wipe out the tag when detach
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)
    2a. if user does not provide any tag, we keep the old tag
    2b. if user provide a new tag, we update the new tag
    2c. provide a way for user to indicate that I want to null out the
previous tag

is my understanding correct?

BR,

On Fri, Mar 1, 2019 at 8:32 AM Dan Smith <dms at danplanet.com> wrote:

> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190301/6cac31bc/attachment-0001.html>