Open Stack

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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp