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