[openstack-dev] [nova] refactoring of resize/migrate

John Garbutt john at johngarbutt.com
Fri Aug 29 17:59:38 UTC 2014


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



More information about the OpenStack-dev mailing list