<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Jay, Timofei,<br>
<br>
Thank you for the info.<br>
<br>
<div class="moz-cite-prefix">On 10/27/2015 08:02 AM, Jay Pipes
wrote:<br>
</div>
<blockquote cite="mid:562EBF30.8060304@gmail.com" type="cite">On
10/22/2015 11:13 AM, Tang Chen wrote: <br>
<blockquote type="cite">On 10/22/2015 05:17 AM, Joshua Harlow
wrote: <br>
<blockquote type="cite">Overall I'm very much inclined to have
three state machines (one <br>
for each type), vs the mix-mash of all three into one state
machine <br>
(which causes the confusion around states in the first diagram
in <br>
that paste). <br>
</blockquote>
<br>
That is an idea. But I would prefer to have one single state
machine <br>
for migration, because resize and evacuate are reusing
migration. <br>
They can be in one state machine. <br>
</blockquote>
<br>
Evacuate does *not* migrate/move anything. Evacuate *rebuilds* VMs
from their original source image. <br>
</blockquote>
<br>
Well, I just dug into the source code. I think there could be some
difference between evacuate in nova server side and client side. In
nova compute, the evacuate API does call rebuild process as you
said. But in novaclient, there is a command "nova
host-evacuate-live", which will live-migrate all running VMs, which
made me believe that evacuate also migrates VMs. Please refer to:<br>
<br>
<a class="moz-txt-link-freetext" href="https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/contrib/host_evacuate_live.py#L72">https://github.com/openstack/python-novaclient/blob/master/novaclient/v2/contrib/host_evacuate_live.py#L72</a><br>
<br>
I think this is also a reason why I always got confused in all these
concepts: cold-migrate, evacuate, evacuate-live, rebuild, resize. <br>
<br>
<br>
About the migration type, I can see that Timofei has tried to split
live-migration into 3 types: <br>
1. block_live_migrate<br>
2. live_migrate_file_level_storage<br>
3. live_migrate_block_stroage<span style="color: rgb(0, 0, 0);
font-family: monospace; font-size: 12px; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: auto; text-align: start;
text-indent: 0px; text-transform: none; white-space: pre; widows:
1; word-spacing: 0px; -webkit-text-stroke-width: 0px; display:
inline !important; float: none; background-color: rgb(221, 255,
221);"></span><br>
<br>
I think it is in driver level, not the user level. It is based on
the type of the storage the VM is using. And I think migration type
should be a multi-level thing.<br>
<br>
Since I'm still a little confused with all the types of migration,
I'd like to share some of my understanding and if they are correct,
I think we can improve it like this.<br>
<br>
1. OpenStack is now supporting resize a VM to another compute node.
If we set "allow_resize_to_same-host", it also supports local
resize. If we are not using memory/CPU hotplug, resize will result
in a shutdown and reconfiguration of VM. <br>
So, there should be 2 types of resize: live (using hotplug) and cold
(often resizing the primary disk).<br>
<br>
2. Evacuate also has 2 types: live (equals to live-migrate) and cold
(rebuild). But evacuate itself does nothing, I mean there is no
actual process called evacuate. evacuate() is just an API calling
rebuild_instance().<br>
<br>
This is from the user level.<br>
<br>
So finally, the migration type would be like this:<br>
<br>
user
compute driver<br>
<br>
live-migrate<br>
live-evacuate live-migrate<br>
live-resize memory/CPU hotplug<br>
<br>
cold-migrate
storage type, etc<br>
clod-evacuate cold-migrate<br>
cold-resize (to self or not)<br>
<br>
rebuild rebuild<br>
(this is not a migration)<br>
<br>
I mean maybe we should handle different things in different levels.
In compute, if the flow is too complex, we can define some more
helper functions to make the main flow easier to understand.<br>
<br>
<blockquote cite="mid:562EBF30.8060304@gmail.com" type="cite"> <br>
I support Nikola in that I believe the different migration types
should have different state machines entirely (but be as
consistent as possible in the naming of terminal states like
"finished" vs "done" etc) <br>
</blockquote>
<br>
OK. Agreed. And maybe also introduce state machines for task_state
and vm_state.<br>
<br>
<blockquote cite="mid:562EBF30.8060304@gmail.com" type="cite"> <br>
<blockquote type="cite">It would be very helpful if the designer
of the migration process <br>
could share his idea. But if it is just some code modified by
many <br>
people many times, I think we should remove the confusing states
and <br>
give a easier, better state machine. <br>
</blockquote>
<br>
There isn't a designer of the migration process :( The original
(crap, IMHO) API from Rackspace Cloud Servers API was used for the
resize functionality in the compute API and it's been a source of
confusion and frustration ever since. Relying on a manual
confirmation or revert input from the user was and continues to be
a horrible idea. <br>
</blockquote>
<br>
Agreed.<br>
<br>
<blockquote cite="mid:562EBF30.8060304@gmail.com" type="cite"> <br>
I believe strongly that we should deprecate the existing migrate,
resize, an live-migrate APIs in favor of a single consolidated,
consistent "move" REST API that would have the following
characteristics: <br>
<br>
* No manual or wait-input states in any FSM graph <br>
</blockquote>
<br>
Yes.<br>
<br>
<blockquote cite="mid:562EBF30.8060304@gmail.com" type="cite"> *
Removal of the term "resize" from the API entirely (the target
resource sizing is an attribute of the move operation, not a
different type of API operation in and of itself) <br>
</blockquote>
<br>
Maybe we can define it in a different level, as I said above. Not
sure.<br>
<br>
<blockquote cite="mid:562EBF30.8060304@gmail.com" type="cite"> *
Transition to a task-based API for poll-state requests. This means
that in order for a caller to determine the state of a VM the
caller would call something like GET
/servers/<UUID>/tasks/<UUID> in order to see the
history of state changes or subtask operations for a particular
request to move a VM <br>
</blockquote>
<br>
Yes.<br>
<br>
<blockquote cite="mid:562EBF30.8060304@gmail.com" type="cite"> <br>
Timofei Durakov (cc'd) has a blueprint for splitting the
live-migration types into separate task classes here: <br>
<br>
<a class="moz-txt-link-freetext"
href="https://review.openstack.org/#/c/225910/">https://review.openstack.org/#/c/225910/</a>
<br>
<br>
I think there's a lot of good ideas in that proposal. Please do
have a look at it. <br>
</blockquote>
<br>
Thanks very much.<br>
<br>
<br>
</body>
</html>