Interesting, It would be great to know what causes the crash if you can
identify it.
What was previously between the designate components and qpid? Simple
router? Stateful firewall? Something else?
Thanks,
Kiall
On 22/07/15 10:53, Jaime Fernández wrote:
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.
I understand that it's a bug of designate-api or oslo.messaging library.
On Tue, Jul 21, 2015 at 1:19 PM, Jaime Fernández <jjja...@gmail.com
<mailto:jjja...@gmail.com>> wrote:
Hi Kiall,
It's a bit strange because only designate-api dies but
designate-sink is also integrated with qpid and survives.
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.
Before testing with Rabbit, as you recommended, we are testing
with qpid in the same VLAN (just to discard the network issue).
I will give you info about my progress.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
