Open Stack

On 11/06/2015 03:47 AM, Tang Chen wrote:
>
> On 11/06/2015 12:45 PM, Chris Friesen wrote:

>> To me, the external API would make more sense as:
>>
>> 1) resize
>>
>> 2) migrate (with option of cold or live, and with option to specify a
>> destination, and with option to override the scheduler if the specified
>> destination doesn't pass filters)
>
> OK. Conceptually speaking, only one case that resize could reuse migration code:
> the current host cannot match the resize condition.

It's not quite that simple.  Generally speaking, in both cases the scheduler 
picks a new host, we stop the guest and maybe move the rootfs files around then 
restart the guest, and handle all the resource tracking along the way.  The 
difference is that resize starts the guest with a different flavor and doesn't 
necessarily need to move to a different host (though by default it will).

So there really is quite a bit of overlap in what needs to happen 
internally...but I don't think that overlap should extend to the external API 
because it's not obvious to the end-user.

> So I don't think resize should be one type of migration.
>
> May I understand it like this:  what we are talking about here is a 3-level
> conception.
>
> user API            nova service         driver
> migrate             live-migration       o ff compute node storage—shared file system
> resize              cold-migration       o n compute node  storage—shared file system
> rebuild                                  o n compute node storage—nonshared file system
> evacuate

Actually, rebuild/evacuate share an underlying nova code path in much the same 
way that resize/cold-migrate share a code path.  What nova calls evacuate is 
basically "rebuild with the same image to a different host".

Chris