Open Stack

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?

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

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