Open Stack

Mark Kirkwood <mark.kirkwood at catalyst.net.nz> wrote on 10/07/2014 02:50:01 
AM:

> 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 
devstack is
> >  > development setups where real external ips for the VMs is usually 
not a
> >  > point of interest.
> >  >
> >  > For instance I never need this...I do sometimes want the VMs to be 
able
> >  > 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 
posted,
> >  > 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 
IP
> > 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 
am
> > 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?

Thanks,
Mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20141008/08a47835/attachment.html>