John Garbutt <j...@johngarbutt.com> wrote on 08/29/2014 07:59:38 PM: > From: John Garbutt <j...@johngarbutt.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@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 <mzoel...@de.ibm.com> wrote: > > Jay Pipes <jaypi...@gmail.com> wrote on 08/27/2014 08:57:08 PM: > > > >> From: Jay Pipes <jaypi...@gmail.com> > >> To: openstack-dev@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev