Open Stack

----- 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.ubuntu at cack.org.uk> wrote:
> 
> > On 7 July 2014 11:37, Sean Dague <sean at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>