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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
