Open Stack

We don't actually envisage a bind9 views solution in the near future.

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).

Designate would then manage that server as if it is in its own pool.

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).


On Mon, 2014-08-25 at 08:59 +0000, Zang MingJie wrote:
> 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/fd0a0148/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140825/fd0a0148/attachment.pgp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6961 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140825/fd0a0148/attachment.bin>