Just a quick followup for future readers of this thread...
On 2/19/16 10:24 PM, John Belamaric wrote:
This turns out to be only half-right. It is true that in Kilo mdns is require, and mdns sends xfr updates to pdns slaves. But, ALSO, designate-central must be configured to write domain information directly to the pdns database.On Feb 19, 2016, at 6:03 PM, Andrew Bogott <abog...@wikimedia.org> wrote: I'm running designate kilo with a pdns backend. I originally set things up in Juno, with designate-central syncing directly to the pdns mysql backend. Everything was stable until my upgrade to Kilo. During the upgrade to Kilo I was advised to add the mdns service, which I did, and I got things mostly working. Every once in a while my pdns service falls over, though, and the pdns logs are VERY strange. As best I can tell, I am now (accidentally) using two simultaneous pdns backends: designate-central writes directly to the pdns mysql database, but mdns also sends sync requests which causes pdns to grab records via AXFR and write them to the database (even though they are already there, thanks to the direct writing by central). As you can imagine, this allows for a host of weird race conditions. The docs for this are baffling -- designate design is changing rapidly and most docs are unversioned, so it's hard for me to know what I'm looking at. Here are my questions: 1) Is it still possible to have central write directly to mysql backend? Can I, in that case, simply turn mdns off, switch my pdns service to master=false slave=false and live happily and simply? 2) If, on the contrary, I'm meant to do this via AXFR, why do the docs still tell me to configure designate with access to the pdns mysql backend?As I understand it, in Kilo and later mdns must be primary and send data to other backends via XFR.
So, it all depends on what designate is doing: domain manipulation are written directly to the pdns database record manipulations are sent to pdns via axfr That answers my earlier question of 'why both?' It's because I needed both. -A _______________________________________________ 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
