On 7 July 2014 11:37, Sean Dague <[email protected]> wrote: > > When it's on a router, it's simpler: use the nexthop, get that metadata > > server. > > Right, but that assumes router control. >
It does, but then that's the current status quo - these things go on Neutron routers (and, by extension, are generally not available via provider networks). > In general, anyone doing singlestack v6 at the moment relies on > > config-drive to make it work. This works fine but it depends what > > cloud-init support your application has. > > I think it's also important to realize that the metadata service isn't > OpenStack invented, it's an AWS API. Which means I don't think we really > have the liberty to go changing how it works, especially with something > like IPv6 support. > Well, as Amazon doesn't support ipv6 we are the trailblazers here and we can do what we please. If you have a singlestack v6 instance there's no compatibility to be maintained with Amazon, because it simply won't work on Amazon. (Also, the format of the metadata server maintains compatibility with AWS but I don't think it's strictly AWS any more; the config drive certainly isn't.) > I'm not sure I understand why requiring config-drive isn't ok. In our > upstream testing it's a ton more reliable than the metadata service due > to all the crazy networking things it's doing. > > I'd honestly love to see us just deprecate the metadata server. The metadata server could potentially have more uses in the future - it's possible to get messages out of it, rather than just one time config - but yes, the config drive is so much more sensible. For the server, and once you're into Neutron, then you end up with many problems - which interface to use, how to get your network config when important details are probably on the metadata server itself...
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
