On 07/07/2014 02:31 PM, Ian Wells wrote: > On 7 July 2014 10:43, Andrew Mann <and...@divvycloud.com > <mailto:and...@divvycloud.com>> wrote: > > What's the use case for an IPv6 endpoint? This service is just for > instance metadata, so as long as a requirement to support IPv4 is in > place, using solely an IPv4 endpoint avoids a number of complexities: > > - Which one to try first? > > > http://en.wikipedia.org/wiki/Happy_Eyeballs > > - Which one is authoritative? > > > If they return the same data, both are (the same as a dualstack website > of any form). > > > - Are both required to be present? I.e. can an instance really not > have any IPv4 support and expect to work? > > > Absolutely yes. "Here, have an address from a space with millions of > addresses, but you won't work unless you can also find one from this > space with an address shortage"... Yes, since we can happily use > overlapping ranges there are many nits you can pick with that statement, > but still. We're trying to plan for the future here and I absolutely > think we should expect singlestack v6 to work. > > > - I'd presume the IPv6 endpoint would have to be link-local scope? > Would that mean that each subnet would need a compute metadata endpoint? > > > Well, the v4 address certainly requires a router (even if the address is > nominally link local), so I don't think it's the end of the world if the > v6 was the same - though granted it would be nice to improve upon that. > In fact, at the moment every router has its own endpoint. We could, for > the minute, do the same with v6 and use the v4-mapped address > |::ffff:169.254.169.254|. > > An alternative would be to use a well known link local address, but > there's no easy way to reserve such a thing officially (though, in > practice, we restrict link locals based on EUID64 and don't let people > change that, so it would only be provider networks with any sort of > issue). Something along the lines of fe80::a9fe:a9fe would probably > suit. You may run into problems with that if you have two clouds linked > to the same provider network; this is a problem if you can't disable the > metadata server on a network, because they will fight over the address. > When it's on a router, it's simpler: use the nexthop, get that metadata > server.
Right, but that assumes router control. > 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. 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. -Sean -- Sean Dague http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev