During our migration from nova-network to neutron, we'll be running
two nova regions in parallel in our cloud. I have designate-sink
working just fine in our existing (nova-network) region, but since sink
is only listening to the rabbit queue of that region it's oblivious to
to events that happen in the Neutron region.
My tentative plan is to run a second designate instance in the
second region, but point it to the same database as designate in the
nova-network region so that the db (and associated mdns services)
contain the aggregate knowledge from both regions. At first blush that
sounds terrible and prone to a million race conditions, but it's not
/that/ different from what the HA designate guide suggests (apart from
using different queues, which may or may not be a deal breaker.)
Am I on the road to deadlocks and database corruption? Is there a
more straightforward solution to this problem that I'm missing?
I'm running version Mitaka -- I've investigated using direct
Neutron integration workflow in the new region instead but it appears to
be broken in Mitaka as per
https://bugs.launchpad.net/neutron/+bug/1616274. I'd be happy to be
wrong about that!
Thanks!
-Andrew
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
