Open Stack

On Thu, Aug 29, 2019 at 6:15 PM Matt Riedemann <mriedemos at gmail.com> wrote:

> On 8/29/2019 10:45 AM, Balázs Gibizer wrote:
> > As feature freeze is closing in I try to raise awareness of the
> > implementation status of the support-move-ops-with-qos-ports
> > <
> https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/support-move-ops-with-qos-ports> bp
>
> > [1].
>
> Thanks for this since I know you've been pushing patches but I haven't
> been able to get myself past the hump that is [3] yet.
>
> >
> > The original goal of the bp was to support every move operations (cold
> > migrate, resize, live-migrate, evacuate, unshelve). Today I have ready
> > and tested (unit + functional) patches proposed for cold migrate and
> > resize [2]. I don't think every move operations will be ready and merged
> > in Train but I still hope that there is a chance for cold migrate and
> > resize to land. Sure I will continue working on supporting the
> > operations that miss the Train in the U release.
>
> This is probably OK since we agreed at the PTG that this blueprint was
> essentially going to be closing gaps in functionality introduced in
> Stein but not adding a new microversion, correct? If so, then doing it
> piece-meal seems OK to me.
>
>
Yeah, and it's already pretty clear about which specific operations can be
done.
I'm OK with having only a few operations done by Train given the API and
the docs are correctly explaining which ones.

>
> > One possible complication in the current patch series is that it
> > proposes the necessary RPC changes for _every_ move operations [3]. This
> > might not be what we want to merge in Train if only cold migrate and
> > resize support fill fit. So I see two possible way forwards:
> > a) Others also feel that cold migrate and resize will fit into Train,
> > and then I will quickly change [3] to only modify those RPCs.
> > b) We agree to postpone the whole series to U. Then I will not spend too
> > much time on reworking [3] in the Train timeframe.
>
> Or (c) we just land that change. I was meaning to review that today
> anyway so this email is coincidental for me. I think passing the request
> spec down to the compute methods is fine and something we'll want to do
> eventually anyway for this series (even if the live migration stuff is
> deferred to U).
>
>
+1
FWIW, since 3 years I would like to pass the RequestSpec down to the
compute but I hadn't time to do it yet.
Cool with me.



> >
> > A connected topic: I proposed patches [4] to add cold migrate and resize
> > tempest coverage to the nova-grenade-multinode (renamed from
> > nova-grenade-live-migrate) job as Matt pointed out in [3] that we don't
> > have such coverage and that my original change in [3] would have broken
> > a mixed-compute-version deployment.
>
> I'm just waiting on CI results for those but since I've already been
> through them in some form and they are pretty small I think there is a
> good chance of landing these soon.
>
> --
>
> Thanks,
>
> Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190830/aa8789c3/attachment.html>