[nova] Status of the bp support-move-ops-with-qos-ports
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
> > .
> 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  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 . 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
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 . 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  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  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).
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  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  that we don't
> > have such coverage and that my original change in  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.
-------------- next part --------------
An HTML attachment was scrubbed...