Hi all,
I am using OpenStack Folsom with nova-network. In the logs I observed some RPC
call timeouts during associate_floating_ip. I assume the timeout is actually a
timeout experienced by RabbitMQ when trying to push the associate_floating_ip
message to a chosen consumer and not a timeout
Have you tried to look at the RabbitMQ web interface to see what could
be stuck ?
Activating it is quite straightforward, as per Ops Guide :
http://docs.openstack.org/trunk/openstack-ops/content/logging_monitoring.html#rabbitmq
-Sylvain
Le 12/04/2013 17:48, Lowery, Mathew a écrit :
Hi all,
Finally, it appears that when an RPC call times out, the original message, at
least is some cases like 'network.hostname' queue, is left in place to be
consumed when a consumer is available. This seems like an odd design--if I
take corrective action in response to an RPC timeout, I don't
3 matches
Mail list logo