<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 28, 2019, 18:29 Matt Riedemann, <<a href="mailto:mriedemos@gmail.com" target="_blank" rel="noreferrer">mriedemos@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2/28/2019 12:08 PM, Matt Riedemann wrote:<br>
> I've put this on the agenda for today's nova meeting. Here are the <br>
> options as I see them:<br>
> <br>
> 1: lift the restriction in this same microversion so that you can attach <br>
> volumes to a shelved offloaded server and specify a tag (despite bug <br>
> 1817927 which we can fix later)<br>
> <br>
> 2: reset the tag during root volume detach and don't allow specifying a <br>
> new tag - this is what we'd get today if we merged Kevin's code as-is<br>
> <br>
> 3: don't reset the tag during root volume detach but don't allow <br>
> overwriting it on root volume attach - this could be poor UX if you need <br>
> to change the tag<br>
> <br>
> 4: same as option 2 but eventually add a new microversion for option 1 <br>
> thus punting the decision<br>
> <br>
> My preferred option is 1 but time is short to be considering this and we <br>
> might screw something up. I don't think option 3 is viable given the <br>
> original tag might not make any sense with a new root volume. Options 2 <br>
> and 4 get us the root volume detach/attach feature in stein as a <br>
> short-term win but is half-baked since we still have more changes to <br>
> make later (and another microversion).<br>
> <br>
> I know another option is just defer to Train when we have more time to <br>
> think about this but we're nearly there on this feature so I'd like to <br>
> get it done if we can reach agreement on the design.<br>
<br>
We talked about this in the nova meeting today:<br>
<br>
<a href="http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-02-28-21.00.log.html#l-95" rel="noreferrer noreferrer noreferrer" target="_blank">http://eavesdrop.openstack.org/meetings/nova/2019/nova.2019-02-28-21.00.log.html#l-95</a><br>
<br>
It sounds like we might be leaning to option 4 for a couple of reasons:<br>
<br>
a) It's getting late in stein to be lifting the restriction on attaching <br>
a volume with a tag to a shelved offloaded server and munging that in <br>
with the root attach/detach volume API change.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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 <span style="font-family:sans-serif">1817927) would be the best choice.</span></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
b) As we got talking I noted that for the same reason as a tag, you <br>
currently cannot attach a multi-attach volume to a shelved offloaded <br>
server, because we don't make the "reserve_block_device_name" RPC call <br>
to the compute service to determine if the driver supports it.<br>
<br>
c) Once we have code in the API to properly translate tags/multiattach <br>
requests to the scheduler (based on [1]) so that we know when we <br>
unshelve that we'll pick a host that supports device tags and <br>
multiattach volumes, we could lift the restriction in the API with a new <br>
microversion.<br>
<br>
If we go this route, it means the API reference for the root volume <br>
detach/attach change needs to mention that the tag will be reset and <br>
cannot be set again on attach of the root volume (at least until we lift <br>
that restriction).<br>
<br>
[1] <a href="https://review.openstack.org/#/c/538498/" rel="noreferrer noreferrer noreferrer" target="_blank">https://review.openstack.org/#/c/538498/</a><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
</blockquote></div></div></div>