Open Stack

John Garbutt <john at johngarbutt.com> wrote on 08/29/2014 07:59:38 PM:

> From: John Garbutt <john at johngarbutt.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev at lists.openstack.org>
> Date: 08/29/2014 08:12 PM
> Subject: Re: [openstack-dev] [nova] refactoring of resize/migrate
> 
> On 28 August 2014 09:50, Markus Zoeller <mzoeller at de.ibm.com> wrote:
> > Jay Pipes <jaypipes at gmail.com> wrote on 08/27/2014 08:57:08 PM:
> >
> >> From: Jay Pipes <jaypipes at gmail.com>
> >> To: openstack-dev at lists.openstack.org
> >> Date: 08/27/2014 08:59 PM
> >> Subject: Re: [openstack-dev] [nova] refactoring of resize/migrate
> >>
> >> On 08/27/2014 06:41 AM, Markus Zoeller wrote:
> >> > The review of the spec to blueprint "hot-resize" has several 
comments
> >> > about the need of refactoring the existing code base of "resize" 
and
> >> > "migrate" before the blueprint could be considered (see [1]).
> >> > I'm interested in the result of the blueprint therefore I want to
> > offer
> >> > my support. How can I participate?
> >> >
> >> > [1] https://review.openstack.org/95054
> >>
> >> Are you offering support to refactor resize/migrate, or are you 
offering
> >
> >> support to work only on the hot-resize functionality?
> >
> > I'm offering support to refactor resize/migrate (with the goal in
> > mind to have a hot resize feature in the future).
> >
> >> I'm very much interested in refactoring the resize/migrate
> >> functionality, and would appreciate any help and insight you might 
have.
> >
> >> Unfortunately, such a refactoring:
> >>
> >> a) Must start in Kilo
> >> b) Begins with un-crufting the simply horrible, inconsistent, and
> >> duplicative REST API and public behaviour of the resize and migrate
> > actions
> >
> > If you give me some pointers to look at I can make some thoughts
> > about them.
> >
> >> In any case, I'm happy to start the conversation about this going in
> >> about a month or so, or whenever Kilo blueprints open up. Until then,
> >> we're pretty much working on reviews for already-approved blueprints 
and
> >
> >> bug fixing.
> >>
> >> Best,
> >> -jay
> >
> > Just ping me and I will participate and give as much as I can.
> 
> Happy to help with some planning/reviewing of specs etc.
> 
> I did have a plan here. It was to move to the conductor the migrate
> and live-migrate code paths. The idea was to simplify the code paths,
> so the commonalty and missing bits could be compared, etc:
> 
https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L470

> 
> That has proved hard to finish, probably because was the wrong
> approach. Turns out there isn't much in common.
> 
> I did also plan on updating the user API, but kinda decided to wait
> for v3 to get sorted, probably incorrectly.
> 
> The main pain with the work is the lack of live-migrate testing in the
> gate, waiting for the multi-node gate work. Its starting to rot in
> there because people are scared of change in there, etc.
> 
> Helping fix some live-migrate bugs, and helping out with live-migrate
> testing, might be a good firsts steps? But depends how you like to
> work really.
> 
> Anyways, happy to see that area get some more love!
> 
> John

The unit tests and bugs are a good start, I agree. By end of this 
week I will start a 2 week vacation but after that I will start 
working in this area. I have a few years of experience in refactoring
tangled code. Let's see what I can do here :)
Let's keep in touch.