[Openstack] How to make DevStack install OpenStack with Neutron?
mspreitz at us.ibm.com
Wed Oct 8 18:40:07 UTC 2014
Mark Kirkwood <mark.kirkwood at catalyst.net.nz> wrote on 10/07/2014 02:50:01
> On 07/10/14 19:44, Mike Spreitzer wrote:
> > Mark Kirkwood <mark.kirkwood at catalyst.net.nz> wrote on 10/07/2014
> > 02:23:36 AM:
> > > I think why this is not documented is the usual use-case for
> > > development setups where real external ips for the VMs is usually
> > > point of interest.
> > >
> > > For instance I never need this...I do sometimes want the VMs to be
> > > to access the internet, and that is pretty easy:
> > >
> > > $ sudo sysctl -w net.ipv4.ip_forward=1
> > > $ sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> > >
> > > For access the other way, yes it's more complex. As others have
> > > you need real ip ranges available in your external network and
> > > (probably) an additional nic in your test box that can be
> > > designated/mapped as br-ex
> > > so that the various routers/gateways in the neutron setup use it.
> > Thanks, Mark. As I mentioned in my original post, I have a block of
> > addresses that I can use as I see fit --- I have a subnet that I
> > control. I do not see why an additional NIC on the host would be
> > needed, it already has a NIC connected to a subnet that I control (I
> > trying to make it easy here).
> True, you can just assign another ip to your nic (in the appropriate
> subnet range) and use that as br-ex - yes, I'm being old fashioned and
> would prefer another nic to make it clear to me what was happening :-)
So I tried using DevStack with FLOATING_RANGE and PUBLIC_NETWORK_GATEWAY
matching the initial network config of my lab machine, and with
Q_FLOATING_ALLOCATION_POOL set to keep Neutron from allocating IPs already
in use on my subnet. I found that DevStack ruined my machine, by setting
PUBLIC_NETWORK_GATEWAY as the address of br-ex. There is an existing bug
for this: https://bugs.launchpad.net/devstack/+bug/1339982 . What
mystifies me is that it is marked as affecting only three people. Are
there really only three people who use DevStack on service machines
(rather than personal ones) and try to get inside/outside communication
working as Neutron intended it? Our CI checking uses DevStack on service
machines, right? Perhaps there is no problem there because checking does
not attempt inside-outside communication?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openstack