openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #08316
Rationale behind using 'rpc:cast' instead of 'rpc:call' for the method "run_instance"
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.
Follow ups