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 <mig...@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 <chang...@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"<mig...@mlavalle.com>; >> *Date: * Wed, Oct 14, 2015 11:22 AM >> *To: * "OpenStack Development Mailing List (not for usage questions)"< >> openstack-dev@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 <chang...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev