openstack team mailing list archive

[Chris Behrens <cbehrens@xxxxxxxxxxxx>]

Right.

We want the API to return as quickly as possible.  It should not block.  I'd argue that live migration should not block the API as well.  Any errors should be reported via the instance faults table,
but it's definitely less important than builds.

Nicolae:  Note that the scheduler also does a 'cast' to the compute host... so the scheduler doesn't block on the build, either.  (However, I'm planning a small change to do an rpc.call to compute so that compute can do some initial verification and possibly return an error to the scheduler.  The build would continue in a greenthread.)

Also:  I think you're referring to a cleanup of mine on 2/29.  live_migration wasn't changed to a rpc.call.  It was a rpc.call before... but I removed a 'return' to make it clear it doesn't really return a response... other than it can raise an exception.

- Chris


On Mar 5, 2012, at 12:56 PM, Vishvananda Ishaya wrote:

> The use of cast is simply so we can return to the user more quickly instead of blocking waiting for a response.  There are some cases where failure handling is a little more complicated and is simplified by using a call.  The live migration is an example of this. It is much less frequently used than run instance, so the extra time due to using a call is an acceptable tradeoff.
> 
> Vish
> 
> On Mar 5, 2012, at 12:41 PM, Nicolae Paladi wrote:
> 
>> Hi, 
>> 
>> this is my first posting in this mailing list, so if it's an RTFM question, please
>> point me to the "FM" :-)
>> 
>> I would like to know what is the rationale behind using an rpc:cast from 
>> scheduler/driver.py when e.g. launching an instance, while rpc.call in driver.py is used only
>> for "trivial" methods, like 'compare_cpu'. 
>> 
>> My guesses would be: 
>> a. Launching an instance might take an arbitrarily long time and holding the process alive
>> until the instance is launched is unfeasible (since it would consume too much memory)
>> b. The call might take too long and it is not possible to specify a timeout for the rpc.call method
>> 
>> I have noticed that in the trunk version in the module scheduler/api.py there is a quite recent 
>> change from 2012-02-29, where the method "live_migration" uses an rpc.call. 
>> I assume, that  in this context, a migrating instance can have the same timeout 
>> behavior as a newly launched instance, so the difference in approaching launch of an instance and 
>> migration of an instance is unclear here.
>> 
>> The reason I am asking is that for my project (launching instances on "trusted" TPM-enabled platforms)
>> I would like to receive an acknowledgement from the compute node that the instance has been launched.
>> 
>> Thank you, 
>> /Nicolae.
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openstack
>> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp