On 11/06/2015 12:45 PM, Chris Friesen wrote:
On 11/05/2015 08:33 AM, Andrew Laski wrote:
On 11/05/15 at 01:28pm, Murray, Paul (HP Cloud) wrote:
Or more specifically, the migrate and resize API actions both call
the resize
function in the compute api. As Ed said, they are basically the same
behind
the scenes. (But the API difference is important.)
Can you be a little more specific on what API difference is important
to you?
There are two differences currently between migrate and resize in the
API:
1. There is a different policy check, but this only really protects
the next bit.
2. Resize passes in a new flavor and migration does not.
Both actions result in an instance being scheduled to a new host. If
they were
consolidated into a single action with a policy check to enforce that
users
specified a new flavor and admins could leave that off would that be
problematic
for you?
To me, the fact that resize and cold migration share the same
implementation is just that, an implementation detail.
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".
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.
And the VM should be migrated to another host, and do the resize.
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
Indeed it is a implementation detail. If we can refactor the source code
as above, maybe it is more clear.
And while we're talking, I don't understand why
"allow_resize_to_same_host" defaults to False. The comments in
https://bugs.launchpad.net/nova/+bug/1251266 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?
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.
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.
Thanks.
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
__________________________________________________________________________
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
