On 7 July 2014 11:37, Sean Dague <s...@dague.net> 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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to