Open Stack

On Fri, 2019-08-30 at 10:06 +0200, Sylvain Bauza wrote:
> 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.

honestly once we have a functional move operation that make it much simpler to use this
feature. so if we only land resize/cold migration that would still be a good step forward.

> 
> > 
> > > 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.
i have had cases in the past where it would have been nice to have but
i think this is a case where it makes sense as any other approch would
be less clean.
> 
> 
> 
> > > 
> > > 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
> > 
> >