Re: [Rdo-list] HOWTO: packstack allinone install with neutron and external connectivity

Since not a day goes by where someone somewhere doesn't ask how to use packstack --allinone with an existing external network, I figured I'd do my best to document here the easiest way that I've come up with so far. This should allow any machine on the network to be able to access launched instances via their floating IPs. Also, at the end of this message, there are some ideas for making this process better that I thought we could discuss. These instructions have been tested on a RHEL 6.4 "minimal" install VM attached to the default libvirt network. Make sure all of your repos are set up first (this example uses rdo-grizzly), and you might as well do a yum update and reboot first to just because it makes things a little more foolproof making sure you have the right kernel, etc. # packstack --allinone --provision-all-in-one-ovs-bridge=n After completion, given a single machine with a current IP of 192.168.122.212/24 via DHCP with gateway of 192.168.122.1: Make /etc/sysconfig/network-scripts/ifcfg-br-ex resemble: (note this file shouldn't exist, but does due to a bug) DEVICE=br-ex DEVICETYPE=ovs TYPE=OVSBridge BOOTPROTO=static IPADDR=192.168.122.212 # Old eth0 IP since we want the network restart to not kill the connection, otherwise pick something outside your dhcp range NETMASK=255.255.255.0 # your netmask GATEWAY=192.168.122.1 # your gateway DNS1=192.168.122.1 # your nameserver ONBOOT=yes Make /etc/sysconfig/network-scripts/ifcfg-eth0 resemble (no BOOTPROTO!): DEVICE=eth0 HWADDR=52:54:00:92:05:AE # your hwaddr TYPE=OVSPort DEVICETYPE=ovs OVS_BRIDGE=br-ex ONBOOT=yes # service network restart NOTE: It is important to do the network restart before setting up the router gateway below, because a network restart takes destroys and recreates br-ex which causes the router's interface in the qrouter-* netns to be deleted, and it won't be recreated without clearing and re-setting the gateway. # . keystonerc_admin # quantum router-gateway-clear router1 # quantum subnet-delete public_subnet You need to recreate the public subnet with an allocation range outside of your external DHCP range and set the gateway to the default gateway of the external network. # quantum subnet-create --name public_subnet --enable_dhcp=False --allocation-pool=start=192.168.122.10,end=192.168.122.20 --gateway=192.168.122.1 public 192.168.122.0/24 # quantum router-gateway-set router1 public You should now be able to follow the steps at http://openstack.redhat.com/Running_an_instance_with_Neutron to launch an instance with external network access. Now, the question is how we make this better. Currently, Gilles Dubreuil is working on a patch to the puppet-vswitch module that can automatically handle the whole "move eth0 into the bridge and give the bridge its IP" issue. He's working through the last of the issues, but it is looking really good. If we are going to handle this automatically in packstack for people, though, it's really best if the external network interface is different from the one we are using for packstack since mucking with the interface you are connecting over is tricky. At the very least, if it is the same interface, then it needs to be configured with a static IP so that when br-ex comes up it will have the same address that eth0 had. Most likely things will pick up fine after the brief network interruption. So, if we go this way, then it would make sense for us to add a config option for PROVISION_DEMO_EXT_IF (which should be determinable automatically, but overridable), PROVISION_DEMO_EXT_POOL and convert the existing PROVISION_DEMO_FLOATRANGE to be PROVISION_DEMO_EXT_CIDR since that was it really is. Also having an option that toggled whether or not we actually did the bridge setup would be advisable. But, in the end it should be possible to have something like: packstack --allinone --use-existing-external-net=y --provision-demo-ext-cidr=192.168.122.0/24 --provision-demo-ext-pool=192.168.122.10,192.168.122.40 Note that this is using the br-ex stuff still. It is also not too difficult to eventually add support for provider networks as well. Thoughts? Terry _______________________________________________ Rdo-list mailing list Rdo-list(a)redhat.com https://www.redhat.com/mailman/listinfo/rdo-list