<div dir="ltr">I moved the virtual machine where designate processes are running into a host in the same LAN than OST. Now the designate-api process does not die anymore (still using qpid). I'm afraid that some network problem or timeout could be the reason for this problem. We'll keep monitoring this process to confirm it.<br><br>I understand that it's a bug of designate-api or oslo.messaging library.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 21, 2015 at 1:19 PM, Jaime Fernández <span dir="ltr"><<a href="mailto:jjjaime@gmail.com" target="_blank">jjjaime@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Kiall,<br></div><div><br>It's a bit strange because only designate-api dies but designate-sink is also integrated with qpid and survives.<br><br></div>These issues are a bit difficult because it is not deterministic. What I've just tested is using a local qpid instance and it looks like the designate-api is not killed any more (however, it's a short period of time). We are going to integrate the host where designate components are installed in the same VLAN than the rest of OST just to check if it's a rare issue with the network.<br><div><div><br></div><div>Before testing with Rabbit, as you recommended, we are testing with qpid in the same VLAN (just to discard the network issue).<br><br>I will give you info about my progress.<br></div></div></div>
</blockquote></div><br></div>