I noticed the BP has been approved, but I really want to understand more on the 
reason, can anyone provide me some hints?

In the BP, it states that "For resize, we need to confirm, as we want to give 
end user an opportunity to rollback". But why do we want to give user an 
opportunity to rollback to resize? And why that reason does not apply to cold 
migration and live migration?

Thanks
--jyh

From: Jay Lau [mailto:[email protected]]
Sent: Thursday, January 16, 2014 3:27 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] why don't we deal with "claims" when live 
migrating an instance?

Hi Scott,
I'm now trying to fix this issue at 
https://blueprints.launchpad.net/nova/+spec/auto-confirm-cold-migration
After the fix, we do not need to "confirm" the cold migration.

http://lists.openstack.org/pipermail/openstack-dev/2014-January/023726.html
Thanks,
Jay

2014/1/17 Scott Devoid <[email protected]<mailto:[email protected]>>
Related question: Why does resize get called (and the VM put in "RESIZE VERIFY" 
state) when migrating from one machine to another, keeping the same flavor?

On Thu, Jan 16, 2014 at 9:54 AM, Brian Elliott 
<[email protected]<mailto:[email protected]>> wrote:

On Jan 15, 2014, at 4:34 PM, Clint Byrum 
<[email protected]<mailto:[email protected]>> wrote:

> Hi Chris. Your thread may have gone unnoticed as it lacked the Nova tag.
> I've added it to the subject of this reply... that might attract them.  :)
>
> Excerpts from Chris Friesen's message of 2014-01-15 12:32:36 -0800:
>> When we create a new instance via _build_instance() or
>> _build_and_run_instance(), in both cases we call instance_claim() to
>> reserve and test for resources.
>>
>> During a cold migration I see us calling prep_resize() which calls
>> resize_claim().
>>
>> How come we don't need to do something like this when we live migrate an
>> instance?  Do we track the hypervisor overhead somewhere in the instance?
>>
>> Chris
>>
It is a good point and it should be done.  It is effectively a bug.

Brian

_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to