<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 11/06/2015 12:45 PM, Chris Friesen
wrote:<br>
</div>
<blockquote cite="mid:563C3071.9090404@windriver.com" type="cite">On
11/05/2015 08:33 AM, Andrew Laski wrote:
<br>
<blockquote type="cite">On 11/05/15 at 01:28pm, Murray, Paul (HP
Cloud) wrote:
<br>
</blockquote>
<br>
<blockquote type="cite">
<blockquote type="cite">Or more specifically, the migrate and
resize API actions both call the resize
<br>
function in the compute api. As Ed said, they are basically
the same behind
<br>
the scenes. (But the API difference is important.)
<br>
</blockquote>
<br>
Can you be a little more specific on what API difference is
important to you?
<br>
There are two differences currently between migrate and resize
in the API:
<br>
<br>
1. There is a different policy check, but this only really
protects the next bit.
<br>
<br>
2. Resize passes in a new flavor and migration does not.
<br>
<br>
Both actions result in an instance being scheduled to a new
host. If they were
<br>
consolidated into a single action with a policy check to enforce
that users
<br>
specified a new flavor and admins could leave that off would
that be problematic
<br>
for you?
<br>
</blockquote>
<br>
<br>
To me, the fact that resize and cold migration share the same
implementation is just that, an implementation detail.
<br>
<br>
From the outside they are different things...one is "take this
instance and move it somewhere else", and the other "take this
instance and change its resource profile".
<br>
<br>
To me, the external API would make more sense as:
<br>
<br>
1) resize
<br>
<br>
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)
<br>
</blockquote>
<br>
OK. Conceptually speaking, only one case that resize could reuse
migration code: the current host cannot match the resize condition.<br>
And the VM should be migrated to another host, and do the resize.<br>
<br>
So I don't think resize should be one type of migration.<br>
<br>
May I understand it like this: what we are talking about here is a
3-level conception.<br>
<br>
user API nova service driver<br>
migrate live-migration o
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a id="d9e1834" class="indexterm" style="color: rgb(0, 0, 0);
font-family: Verdana, Geneva, sans-serif; font-size:
13.3333330154419px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: left; text-indent: 0px; text-transform:
none; white-space: normal; widows: 1; word-spacing: 0px;
-webkit-text-stroke-width: 0px;">ff compute node storage—shared
file system</a><br>
resize cold-migration o
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a id="d9e1834" class="indexterm" style="color: rgb(0, 0, 0);
font-family: Verdana, Geneva, sans-serif; font-size:
13.3333330154419px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: left; text-indent: 0px; text-transform:
none; white-space: normal; widows: 1; word-spacing: 0px;
-webkit-text-stroke-width: 0px;">n compute node storage—shared
file system</a><br>
rebuild o
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a id="d9e1834" class="indexterm" style="color: rgb(0, 0, 0);
font-family: Verdana, Geneva, sans-serif; font-size:
13.3333330154419px; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: auto; text-align: left; text-indent: 0px; text-transform:
none; white-space: normal; widows: 1; word-spacing: 0px;
-webkit-text-stroke-width: 0px;">n compute node storage—nonshared
file system</a><br>
evacuate<br>
<br>
Indeed it is a implementation detail. If we can refactor the source
code as above, maybe it is more clear.<br>
<br>
<blockquote cite="mid:563C3071.9090404@windriver.com" type="cite">
<br>
<br>
And while we're talking, I don't understand why
"allow_resize_to_same_host" defaults to False. The comments in
<a class="moz-txt-link-freetext" href="https://bugs.launchpad.net/nova/+bug/1251266">https://bugs.launchpad.net/nova/+bug/1251266</a> say that it's not
intended to be used in production, but doesn't give a rationale
for that statement. If you're using local storage and you just
want to add some more CPUs/RAM to the instance, wouldn't it be
beneficial to avoid the need to copy the rootfs?
<br>
</blockquote>
<br>
I'm sorry I don't know why it is False by default. But if we can
refactor the source code, and split resize and migrate conceptually,
I think we don't need this option any more.<br>
<br>
And another question about resize, shall we think about CPU/memory
hotplug ? AFAIK, Linux kerenl and qemu are now supporting memory
hotplug. CPU hotplug in qemu is still being developed. I was
thinking resize could use these functionalities.<br>
<br>
Thanks.<br>
<br>
<blockquote cite="mid:563C3071.9090404@windriver.com" type="cite">
<br>
Chris
<br>
<br>
__________________________________________________________________________
<br>
OpenStack Development Mailing List (not for usage questions)
<br>
Unsubscribe:
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
<br>
<br>
</blockquote>
<br>
</body>
</html>