Open Stack

Hi,

While #1 does improve things further it doesn't cover the use case where
you have 2 tenants and you would like to have the VMs spun up different dns
domains.

I suspect this was intentionally left out?

Dani

On Wed, Oct 14, 2015 at 11:39 PM, Miguel Lavalle <miguel at mlavalle.com>
wrote:

> Zhi Chang,
>
> You got all the steps correct. A few clarifications:
>
>
>    1. Address 104.130.78.191 is the ip address of my devstack VM. When
>    you deploy Designate in devstack, it starts an instance of PowerDNS for
>    you. Designate then pushes all its zones and records to that PowerDNS
>    instance. When I say "dig my-instance.my-example.org @104.130.78.191"
>    I am instructing dig to direct the lookup to the DNS server @
>    104.130.78.191: in other words, my PowerDNS instance
>    2. For you to be able to execute the same steps in your devstack, you
>    need:
>       - The code in patchset https://review.openstack.org/#/c/212213/
>       - The modified nova code in nova/network/neutronv2/api.py that I
>       haven't pushed to Gerrit yet
>       - Configure a few parameters in /etc/neutron/neutron.conf
>       - Migrate the Neutron database, because I added columns to a couple
>       of tables
>
> Let me know if you want to try this in your devstack. If the answer is
> yes, I will let you know when I push the nova change to gerrit. At that
> point, I will provide detailed steps to accomplish point 2 above
>
> Best regards
>
>
> Miguel
>
>
> On Wed, Oct 14, 2015 at 12:53 AM, Zhi Chang <changzhi at unitedstack.com>
> wrote:
>
>> Hi, Miguel
>>     Thank you so much for your reply. You are so patient!
>>     After reading your reply, I still have some questions to ask you. :-)
>>     Below, is my opinion about the
>> http://paste.openstack.org/show/476210/, please read it and tell me
>> whether I was right.
>>     (1). Define a DNS domain
>>     (2). Update a network's "dns_domain" attribute to the DNS domain
>> which defined in the step1
>>     (3). Create a VM in this network. The instance's port will assign
>> instance's hostname to it's dns_name attribute
>>     (4). Create a floating IP for this VM
>>     (5). In Designate, there will be generate a new A record. This record
>> is a link between floating IP and dns_name+domain_name. Just like your
>> record: deec921d-b630-4479-8932-c5ec7c530820 | A |
>> my-instance.my-example.org. | 172.24.4.3
>>   (6). I am don't understand where the IP address "104.130.78.191" comes
>> from. I think this address is a public DNS, just like 8.8.8.8. Does it
>> right?
>>    (7). I can dig "my-instance.my-example.org." by a public DNS. And the
>> result is the floating IP.
>>
>> Does my understanding was right?
>>
>> Hope For Your Reply.
>> Thanks
>> Zhi Chang
>>
>> ------------------ Original ------------------
>> *From: * "Miguel Lavalle"<miguel at mlavalle.com>;
>> *Date: * Wed, Oct 14, 2015 11:22 AM
>> *To: * "OpenStack Development Mailing List (not for usage questions)"<
>> openstack-dev at lists.openstack.org>;
>> *Subject: * Re: [openstack-dev] [Neutron][dns]What the meaning
>> of"dns_assignment" and "dns_name"?
>>
>> Zhi Chang,
>>
>> Thank you for your questions. We are in the process of integrating
>> Neutron and Nova with an external DNS service, using Designate as the
>> reference implementation. This integration is being achieved in 3 steps.
>> What you are seeing is the result of only the first one. These steps are:
>>
>> 1) Internal DNS integration in Neutron, which merged recently:
>> https://review.openstack.org/#/c/200952/. As you may know, Neutron has
>> an internal DHCP / DNS service based on dnsmasq for each virtual network
>> that you create. Previously, whenever you created a port on a given
>> network, your port would get a default host name in dnsmasq of the form
>> 'host-xx-xx-xx-xx.openstacklocal.", where xx-xx-xx-xx came from the port's
>> fixed ip address "xx.xx.xx.xx" and "openstacklocal" is the default domain
>> used by Neutron. This name was generated by the dhcp agent. In the above
>> mentioned patchset, we are moving the generation of these dns names to the
>> Neutron server, with the intent of allowing the user to specify it. In
>> order to do that, you need to enable it by defining in neutron.conf the
>> 'dns_domain' parameter with a value different to the default
>> 'openstacklocal'. Once you do that, you can create or update a port and
>> assign a value to its 'dns_name' attribute. Why is this useful? Please read
>> on.
>>
>> 2) External DNS integration in Neutron. The patchset is being worked now:
>> https://review.openstack.org/#/c/212213/. The functionality implemented
>> here allows Neutron to publish the dns_name associated with a floating ip
>> under a domain in an external dns service. We are using Designate as the
>> reference implementation, but the idea is that in the future other DNS
>> services can be integrated.. Where does the dns name and domain of the
>> floating ip come from? It can come from 2 sources. Source number 1 is the
>> floating ip itself, because in this patchset we are adding a dns_name and a
>> dns_domain attributes to it. If the floating ip doesn't have a dns name and
>> domain associated with it, then they can come from source number 2: the
>> port that the floating ip is associated with (as explained in point 1,
>> ports now can have a dns_name attribute) and the port's network, since this
>> patchset adds dns_domain to networks.
>>
>> 3) Integration of Nova with Neutron's DNS. I have started the
>> implementation of this and over the next few days will push the code to
>> Gerrit for first review. When an instance is created, nova will request to
>> Neutron the creation of the corresponding port specifying the instance's
>> hostname in the port's 'dns_name' attribute (as explained in point 1). If
>> the network where that port lives has a dns_domain associated with it (as
>> explained in point 2) and you assign a floating ip to the port, your
>> instance's hostname will be published in the external dns service.
>>
>> To make it clearer, here I walk you through an example that I executed in
>> my devstack: http://paste.openstack.org/show/476210/
>>
>> As mentioned above, we also allow the dns_name and dns_domain to be
>> published in the external dns to be defined at the floating ip level. The
>> reason for this is that we envision a use case where the name and ip
>> address made public in the dns service are stable, regardless of the nova
>> instance associated with the floating ip.
>>
>> If you are attending the upcoming Tokyo summit, you could attend the
>> following talk for further information:
>> http://openstacksummitoctober2015tokyo.sched.org/event/5cbdd5fb4a6d080f93a5f321ff59009c#.Vh3KMZflRz2
>> Looking forward to see you there!
>>
>> Hope this answers your questions
>>
>> Best regards
>>
>> Miguel Lavalle
>>
>> On Tue, Oct 13, 2015 at 9:58 AM, Zhi Chang <changzhi at unitedstack.com>
>> wrote:
>>
>>> Hi, all
>>>     I install the latest devstack and create a vm by nova. I get the
>>> port's info which created by Neutron. I'm confused that what the meaning of
>>> column "dns_assignment" and column "dns_name".
>>>     First, column "dns_assignment" is a read-only attribute. What is it
>>> used for? I think that this column is useless except shows DNS infomation
>>> (include hostname, ip, fqdn). Does my thought right?
>>>     Second, I don't quite understand what the meaning of column
>>> "dns_name". I can update this column, but there is nothing happen when my operation
>>> was done. In other words, this column has no change when I run "neutron
>>> port-update xxx --dns_name=test". What the column "dns_name" use for?
>>>
>>>
>>>
>>> Thanks
>>> Zhi Chang
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20151016/b57cbaf2/attachment.html>