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