[Openstack] internal dns management in mitaka

Brandon Sawyers brandor5 at gmail.com
Wed Sep 7 23:04:34 UTC 2016


On Wed, Sep 7, 2016 at 6:47 PM Turbo Fredriksson <turbo at bayour.com> wrote:

> On Sep 7, 2016, at 11:03 PM, Brandon Sawyers wrote:
>
> >
> https://openstack.nimeyo.com/83652/openstack-neutron-designate-tenancy-neutrons-integration?start=0#a_list_title
>
> "and the zone from the private network".
>
> Meaning, "there can be only one"! And it's automatic (this
> part: "the network is set to publish all port FQDNs to Designate").
>
> So, it is as I described - you set the "dns_domain" on the network
> and "dns_name" on the port, and it's automatic. But more than that
> you can't do. I.e., your original question
>
>     What I'd like to be able to do is have each private network (or project
>     maybe?) be able to control the domain names attached to their guests.
>
> Can only be done with Designate, not Neutron.
>
> Unless what you want is what I _do not_ - one network, one domain.
> If you want one network, several different domains, then you can't do
> that this way. You have to do it manually.
>
> > | dns_assignment        | {"hostname": "test", "ip_address": "10.0.0.15",
> > "fqdn": "test.cloud.int."}       |
>
> So that's the internal Neutron/DNSMasq DNS I was talking about. Don't know
> how much use that actually is, but if I remember the docs I read months ago
> (briefly! :) about this, that _SHOULD_ be possible to use internally within
> the instances.
>
> That's the private IP..
>
> > | dns_name              | test
>                                    |
> > | fixed_ips             | {"subnet_id":
> "3a6bedd6-3c8f-4bfb-8e2b-60db8c711afd", "ip_address": "10.0.0.15"} |
>
> Do you have "dns_domain" on the network that's the "father" of the subnet
> "3a6bedd6-3c8f-4bfb-8e2b-60db8c711afd"?
>
> > | network_id            | a42ea9bf-2aa8-4097-a0be-fce7db9a2707
> >                                            |
>
> That network.
>
> > | dns_domain                | test.internal.                       |
> > | id                        | a42ea9bf-2aa8-4097-a0be-fce7db9a2707 |
>
> Ah, yes. Good.
>
> > | 30efcfd8-220c-44fd-ac4e-da85efc3a497 | test.test.internal.       | A
>   | 172.21.14.62
> | ACTIVE | NONE   |
>
> > Everything that should be there seems to be. Even the floating ip of a
> > previous iteration.
>
> So where's the floating IP [port] entry for _this_ instance? And does
> that have "dns_name" set?
>

>
> So let's recap:
>
>   1. You have the "dns_domain" set on the network.
>   2. You have the "dns_name" set on [one of] the port(s) - the private
>      one.
>
> So you have an entry for "test.test.internal." (correct - first "test" is
> the "dns_name" in the port, the "test.internal." is from the network)
> pointing to "172.21.14.62" (wrong!).
>
> It _should_ (if I'm reading your output correctly) have pointed to
> "10.0.0.15" (because that's the IP of the port).
>
> But you say "of a previous iteration"! What do you mean? If you delete
> the port(s) etc, is the domain updated? I.e., is that entry/line I quoted
> above gone?
>
That's a floating ip that I set in an earlier test but didn't release
before killing the instance. It shouldn't be there. If I had released
before deleting the entry wouldn't be there.

>
> If yes, what happens if you DON'T add a floating IP when you add (create)
> everything back again? Is the domain pointing to the private then? Maybe
> the latest port overwrites the previous? Because I'm assuming that you're
> adding the floating IP after the private IP.. ?
>
 No, it never points at the private ip, but this is what I want.


> I can't remember if I ever tested having two identical A records pointing
> to two different IPs (I just have very vague, nagging feeling that that
> isn't possible - I'm probably wrong, but the feeling is still there)..
> In Bind, that's perfectly legal, but I don't know if Designate supports
> that.
> --
> I love deadlines. I love the whooshing noise they
> make as they go by.
> - Douglas Adams
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20160907/b4917736/attachment.html>


More information about the Openstack mailing list