Open Stack

On Thu, Feb 28, 2019, 18:29 Matt Riedemann, <mriedemos at gmail.com> wrote:

> On 2/28/2019 12:08 PM, Matt Riedemann wrote:
> > I've put this on the agenda for today's nova meeting. Here are the
> > options as I see them:
> >
> > 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)
> >
> > 2: reset the tag during root volume detach and don't allow specifying a
> > new tag - this is what we'd get today if we merged Kevin's code as-is
> >
> > 3: don't reset the tag during root volume detach but don't allow
> > overwriting it on root volume attach - this could be poor UX if you need
> > to change the tag
> >
> > 4: same as option 2 but eventually add a new microversion for option 1
> > thus punting the decision
> >
> > My preferred option is 1 but time is short to be considering this and we
> > might screw something up. I don't think option 3 is viable given the
> > original tag might not make any sense with a new root volume. Options 2
> > and 4 get us the root volume detach/attach feature in stein as a
> > short-term win but is half-baked since we still have more changes to
> > make later (and another microversion).
> >
> > I know another option is just defer to Train when we have more time to
> > think about this but we're nearly there on this feature so I'd like to
> > get it done if we can reach agreement on the design.
>
> We talked about this in the nova meeting today:
>
>
> http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-02-28-21.00.log.html#l-95
>
> It sounds like we might be leaning to option 4 for a couple of reasons:
>
> a) It's getting late in stein to be lifting the restriction on attaching
> a volume with a tag to a shelved offloaded server and munging that in
> with the root attach/detach volume API change.
>

Yeah, 1 and 2 end up with the same situation: a tagged volume becoming
tagless. In 1 it's ignored by the host during unshelve, in 2 it's reset
during the detach. So it becomes a matter of what's faster to implement, so
2 (well, 4, really, because we still need to fix 1817927) would be the best
choice.


> b) As we got talking I noted that for the same reason as a tag, you
> currently cannot attach a multi-attach volume to a shelved offloaded
> server, because we don't make the "reserve_block_device_name" RPC call
> to the compute service to determine if the driver supports it.
>
> c) Once we have code in the API to properly translate tags/multiattach
> requests to the scheduler (based on [1]) so that we know when we
> unshelve that we'll pick a host that supports device tags and
> multiattach volumes, we could lift the restriction in the API with a new
> microversion.
>
> If we go this route, it means the API reference for the root volume
> detach/attach change needs to mention that the tag will be reset and
> cannot be set again on attach of the root volume (at least until we lift
> that restriction).
>
> [1] https://review.openstack.org/#/c/538498/
>
> --
>
> Thanks,
>
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190228/c2ec61fa/attachment-0001.html>