Open Stack

On 07/07/2014 02:31 PM, Ian Wells wrote:
> On 7 July 2014 10:43, Andrew Mann <andrew at divvycloud.com
> <mailto:andrew at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140707/86f8c2f1/attachment.pgp>