I think the DNS idea's going to run into problems for tenants that want to run their own, or have existing DNS servers. It may not play nicely with Designate as well.
Kevin ________________________________ From: Ian Wells [ijw.ubu...@cack.org.uk] Sent: Wednesday, September 09, 2015 12:17 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron] cloud-init IPv6 support Neutron already offers a DNS server (within the DHCP namespace, I think). It does forward on non-local queries to an external DNS server, but it already serves local names for instances; we'd simply have to set one aside, or perhaps use one in a 'root' but nonlocal domain (metadata.openstack e.g.). In fact, this improves things slightly over the IPv4 metadata server: IPv4 metadata is usually reached via the router, whereas in ipv6 if we have a choice over addresses with can use a link local address (and any link local address will do; it's not an address that is 'magic' in some way, thanks to the wonder of service advertisement). And per previous comments about 'Amazon owns this' - the current metadata service is a de facto standard, which Amazon initiated but is not owned by anybody, and it's not the only standard. If you'd like proof of the former, I believe our metadata service offers /openstack/ URLs, unlike Amazon (mirroring the /openstack/ files on the config drive); and on the latter, config-drive and Amazon-style metadata are only two of quite an assortment of data providers that cloud-init will query. If it makes you think of it differently, think of this as the *Openstack* ipv6 metadata service, and not the 'will-be-Amazon-one-day-maybe' service. On 8 September 2015 at 17:03, Clint Byrum <cl...@fewbar.com<mailto:cl...@fewbar.com>> wrote: Neutron would add a soft router that only knows the route to the metadata service (and any other services you want your neutron private network vms to be able to reach). This is not unique to the metadata service. Heat, Trove, etc, all want this as a feature so that one can poke holes out of these private networks only to the places where the cloud operator has services running. Excerpts from Fox, Kevin M's message of 2015-09-08 14:44:35 -0700: > How does that work with neutron private networks? > > Thanks, > Kevin > ________________________________________ > From: Clint Byrum [cl...@fewbar.com<mailto:cl...@fewbar.com>] > Sent: Tuesday, September 08, 2015 1:35 PM > To: openstack-dev > Subject: Re: [openstack-dev] [Neutron] cloud-init IPv6 support > > Excerpts from Nir Yechiel's message of 2014-07-07 09:15:09 -0700: > > AFAIK, the cloud-init metadata service can currently be accessed only by > > sending a request to http://169.254.169.254, and no IPv6 equivalent is > > currently implemented. Does anyone working on this or tried to address this > > before? > > > > I'm not sure we'd want to carry the way metadata works forward now that > we have had some time to think about this. > > We already have DHCP6 and NDP. Just use one of those, and set the host's > name to a nonce that it can use to lookup the endpoint for instance > differentiation via DNS SRV records. So if you were told you are > > d02a684d-56ea-44bc-9eba-18d997b1d32d.region.cloud.com<http://d02a684d-56ea-44bc-9eba-18d997b1d32d.region.cloud.com> > > Then you look that up as a SRV record on your configured DNS resolver, > and connect to the host name returned and do something like GET > /d02a684d-56ea-44bc-9eba-18d997b1d32d > > And viola, metadata returns without any special link local thing, and > it works like any other dual stack application on the planet. > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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
