----- Original Message ----- > A bit more... > > > I have OpenStack IceHouse with Trusty up and running, *almost* in an > IPv6-Only environment, *there is only one place* that I'm still using IPv4, > which is: > > > 1- For Metadata Network. > > > This means that, soon as OpenStack enables Metadata over IPv6, I'll kiss > goodbye IPv4. For real, I can not handle IPv4 networks anymore... So many > NAT tables and overlay networks, that it creeps me out!! lol > > > NOTE: I'm using "VLAN Provider Networks" with static (no support for SLAAC > upstream routers in OpenStack yet) IPv6 address for my tenants, so, I'm not > using GRE/VXLAN tunnels, and that is another place of OpenStack that still > depends on IPv4, for its tunnels... >
Just to make sure I got you right here - would you expect to run the overlay tunnels over an IPv6 transport network? > > As I said, everything else is running over IPv6, like RabbitMQ, MySQL, > Keystone, Nova, Glance, Cinder, Neutron (API endpoint), SPICE Consoles and > Servers, the entire Management Network (private IPv6 address space - > fd::/64) and etc... So, why do we need IPv4? I don't remember... :-P > Good to hear. Would you mine sharing your config/more details around the deployment? > Well, Amazon doesn't support IPv6... Who will be left behind with smelly > IPv4 and ugly "VPCs topologies"?! Not us. ;-) > > Best! > Thiago > > > On 7 July 2014 15:50, Ian Wells <ijw.ubu...@cack.org.uk> wrote: > > > 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 > > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev