Hi, <div><br></div><div>this is my first posting in this mailing list, so if it's an RTFM question, please</div><div>point me to the "FM" :-)</div><div><br></div><div>I would like to know what is the rationale behind using an rpc:cast from </div>
<div>scheduler/driver.py when e.g. launching an instance, while rpc.call in driver.py is used only</div><div>for "trivial" methods, like 'compare_cpu'. </div><div><br></div><div>My guesses would be: </div>
<div>a. Launching an instance might take an arbitrarily long time and holding the process alive</div><div>until the instance is launched is unfeasible (since it would consume too much memory)</div><div>b. The call might take too long and it is not possible to specify a timeout for the rpc.call method</div>
<div><br></div><div>I have noticed that in the trunk version in the module scheduler/api.py there is a quite recent </div><div>change from 2012-02-29, where the method "live_migration" uses an rpc.call. </div><div>
I assume, that  in this context, a migrating instance can have the same timeout </div><div>behavior as a newly launched instance, so the difference in approaching launch of an instance and </div><div>migration of an instance is unclear here.</div>
<div><br></div><div>The reason I am asking is that for my project (launching instances on "trusted" TPM-enabled platforms)</div><div> I would like to receive an acknowledgement from the compute node that the instance has been launched.</div>
<div><br></div><div>Thank you, </div><div>/Nicolae.</div><div><br></div>