<div dir="ltr"><font face="courier new, monospace">I don't like the idea that uses bind9 views to split networks, due to follow reasons:<br><br>the designate may not or hard to know the router's public address<br>non-router may exist for some isolate networks<br>
there is no routes in our dhcp namespace currently<br><br>I suggest run one bind9 instance for each network which has domain support, and introduce a designate-bind9-agent to control the bind9 instances.<br><br>+--------------+--------------+------------- network<br>
| | |<br>+---------+ +---------+ +---------+<br>|instance | | dnsmasq | | bind9 |<br>+---------+ +---------+ +---------+</font><div><font face="courier new, monospace"> | |</font></div>
<div><font face="courier new, monospace"> +----------+ </font><span style="font-family:'courier new',monospace">+---------+</span><font face="courier new, monospace"><br> |dhcp agent| </font><span style="font-family:'courier new',monospace">|dns agent|</span></div>
<div><font face="courier new, monospace"> +----------+ </font><span style="font-family:'courier new',monospace">+---------+</span><font face="courier new, monospace"><br><br>On Tue, Aug 12, 2014 at 1:41 AM, Hayes, Graham <<a href="mailto:graham.hayes@hp.com">graham.hayes@hp.com</a>> wrote:<br>
><br>> kazuhiro MIYASHITA,<br>><br>> As designate progresses with server pools, we aim to have support for a<br>> 'private' dns server, that could run within a neutron network - is that<br>> the level of integration you were referring to?<br>
><br>> That is, for the time being, a long term goal, and not covered by Carl's<br>> Kilo blueprint.<br>><br>> We talked with both people from both Neutron and Nova in Atlanta, and<br>> worked out the first steps for designate / neutron integration (auto<br>
> provisioning of records)<br>><br>> For that level of integration, we are assuming that a neutron router<br>> will be involved in DNS queries within a network.<br>><br>> Long term I would prefer to see a 'private pool' connecting directly to<br>
> the Network2 (like any other service VM (LBaaS etc)) and have dnsmasq<br>> pass on only records hosted by that 'private pool' to designate.<br>><br>> This is all yet to be fleshed out, so I am open to suggestions. It<br>
> requires that we complete server pools, and that work is only just<br>> starting (it was the main focus of our mid-cycle 2 weeks ago).<br>><br>> Graham<br>><br>> On Mon, 2014-08-11 at 11:02 -0600, Carl Baldwin wrote:<br>
> > kazuhiro MIYASHITA,<br>> ><br>> > I have done a lot of thinking about this. I have a blueprint on hold<br>> > until Kilo for Neutron/Designate integration [1].<br>> ><br>> > However, my blueprint doesn't quite address what you are going after<br>
> > here. An assumption that I have made is that Designate is an external<br>> > or internet facing service so a Neutron router needs to be in the<br>> > datapath to carry requests from dnsmasq to an external network. The<br>
> > advantage of this is that it is how Neutron works today so there is no<br>> > new development needed.<br>> ><br>> > Could you elaborate on the advantages of connecting dnsmasq directly<br>> > to the external network where Designate will be available?<br>
> ><br>> > Carl<br>> ><br>> > [1] <a href="https://review.openstack.org/#/c/88624/">https://review.openstack.org/#/c/88624/</a><br>> ><br>> > On Mon, Aug 11, 2014 at 7:51 AM, Miyashita, Kazuhiro<br>
> > <<a href="mailto:miyakz@jp.fujitsu.com">miyakz@jp.fujitsu.com</a>> wrote:<br>> > > Hi,<br>> > ><br>> > > I want to ask about neutron and designate integration.<br>> > > I think dnsmasq fowards DNS request from instance to designate is better.<br>
> > ><br>> > > +------------------------+<br>> > > |DNS server(designate) |<br>> > > +------------------------+<br>
> > > |<br>> > > -----------------+--------------+------ Network1<br>> > > |<br>> > > +--------+<br>> > > |dnsmasq |<br>
> > > +--------+<br>> > > |<br>> > > -+--------------+---------------------- Network2<br>> > > |<br>> > > +---------+<br>> > > |instance |<br>
> > > +---------+<br>> > ><br>> > > Because it's simpler than virtual router connects Network1 and Network2.<br>> > > If router connects network, instance should know where DNS server is. it is complicated.<br>
> > > dnsmasq returns its ip address as dns server in DHCP replay by ordinary, so,<br>> > > I think good dnsmasq becomes like a gateway to designate.<br>> > ><br>> > > But, I can't connect dnsmasq to Network1. because of today's neutron design.<br>
> > ><br>> > > Question:<br>> > > Does designate design team have a plan such as above integration?<br>> > > or other integration design?<br>> > ><br>> > > *1: Network1 and Network2 are deployed by neutron.<br>
> > > *2: neutron deploys dnsmasq as a dhcp server.<br>> > > dnsmasq can forward DNS request.<br>> > ><br>> > > Thanks,<br>> > ><br>> > > kazuhiro MIYASHITA<br>> > ><br>
> > ><br>> > ><br>> > ><br>> > > _______________________________________________<br>> > > OpenStack-dev mailing list<br>> > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>> ><br>> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>> _______________________________________________<br>> OpenStack-dev mailing list<br>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font><br></div></div>