<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/4.6.6">
</HEAD>
<BODY>
We don't actually envisage a bind9 views solution in the near future.<BR>
<BR>
I would imagine (this has not yet been discussed) that we would have service VMs (one per network / tenant) connected to the neutron network, and a control network (like how Trove are doing the neutron integration).<BR>
<BR>
Designate would then manage that server as if it is in its own pool.<BR>
<BR>
We would need to find a way for neutrons dnsmasq to pass certain queries to the designate controlled server, but that should not be an issue (AFAIK it can be done with a few lines in the dnsmasq config).<BR>
<BR>
<BR>
On Mon, 2014-08-25 at 08:59 +0000, Zang MingJie wrote:
<BLOCKQUOTE TYPE=CITE>
    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>
    +---------+    +---------+    +---------+ 
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
                   |              |
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
                   +----------+   +---------+<BR>
                   |dhcp agent|   |dns agent|
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
                   +----------+   +---------+<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>
    <BR>
    <BR>
</BLOCKQUOTE>
</BODY>
</HTML>