Thank you Russel, i'll wait for the fix<div><br></div><div>Best Regards<br><br><div class="gmail_quote">2012/5/29 Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 05/28/2012 01:21 PM, Clint Byrum wrote:<br>
> Looks to me that you need to make sure the other side of that RPC<br>
> connection is up before nova-compute. I am not familiar with the specifics<br>
> of what Nova needs at startup, but I'd guess this is nova-api or keystone.<br>
> Thats a pretty easy thing to do in a single system (just mess with the<br>
> upstart jobs or init scripts) but across multiple systems, you'll need<br>
> some kind of orchestration layer, and even then modeling the dependencies<br>
> on the network with some other tool seems like something just begging<br>
> to break.<br>
<br>
</div>In this case, it's nova-compute expecting nova-network to be up and<br>
running when it starts up.  This also causes a problem when restarting<br>
all of the services at the same time, as seen here:<br>
<br>
<a href="https://bugs.launchpad.net/nova/+bug/999698" target="_blank">https://bugs.launchpad.net/nova/+bug/999698</a><br>
<div class="im"><br>
> Instead, the timeout should just be multiple minutes during startup, and<br>
> the services should all be able to start in parallel if they are on the<br>
> same box. I always think of one of those HP EcoPOD that is pre-installed<br>
> with everything you need for OpenStack, and just shipped and then turned<br>
> on. You could spend a lot of time trying to get that order just right,<br>
> or you could just have everything extend their timeouts and get as far<br>
> as they can without contact with the other services.<br>
><br>
> nova-compute doesn't *know* that the other side is in error, it just<br>
> knows that it is not responding. This is not a problem with nova-compute,<br>
> so why should nova-compute fail so quickly? One could even argue that<br>
> nova-compute should wait *forever* for the other side. From an ops<br>
> standpoint, they're both "down", so why make the operations team take<br>
> two actions when the actual broken service recovers?<br>
<br>
</div>The problem is that since nova-network isn't up, the request gets lost.<br>
 nova-compute is sitting there waiting for a response to a message that<br>
was never even received most likely.  It's also possible that<br>
nova-network received the  message but the service stopped before it<br>
responded (but that is less likely, I think).<br>
<br>
The message queues get created by the consumer of messages in nova.  So,<br>
in this case, nova-network creates the queue.  Some possible solutions:<br>
<br>
1) We could adjust this code path to just loop around and try again if<br>
it hits a timeout.  We could make the timeout much shorter than the<br>
default, to make recover quicker.<br>
<br>
The downside would be that we're fixing a single place, when this issue<br>
could pop up elsewhere.<br>
<br>
2) We could make it so the sender creates the queue if it doesn't exist.<br>
<br>
This is good because it covers all cases.  The bad thing is that we<br>
would not be able to set the queue to be auto-deleted in this case, so<br>
we could end up with a "leak" of unwanted message queues.<br>
<br>
<br>
I'm tempted to just write a patch that does #1 for now to address the<br>
immediate issue and then do something better later if we come up with<br>
something.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Russell Bryant<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</div></div></blockquote></div><br></div>