Description of problem: The documentation at http://openstack.redhat.com/Quickstart assumes use of nova-network instead of neutron which the Havana release of RDO now appears to configure by default. Instances cannot reach the external network and points beyond it without first adding the external physical network interface on the host (e.g., eth0) as a port on br-ex using ovs-vsctl. For example: ovs-vsctl add-port br-ex eth0 For installations with a single network interface handling both management and instance traffic, adding the latter to br-ex will interrupt network connectivity until one moves the IP address (e.g., 192.168.1.101) from the original interface to br-ex. After moving the IP address, the host should regain network connectivity and the instance should be able to reach some IP address outside of the internal/fixed network. The documentation should mention this additional configuration and the temporary interruption of network connectivity. Also, it should include the necessary changes to the associated network interface configuration files in /etc/sysconfig/network-scripts. For example: /etc/sysconfig/network-scripts/ifcfg-br-ex: DEVICE="br-ex" DEVICETYPE="ovs" TYPE="OVSBridge" BOOTPROTO="static" IPADDR="192.168.1.101" NETMASK="255.255.255.0" GATEWAY="192.168.1.1" ONBOOT="yes" /etc/sysconfig/network-scripts/ifcfg-eth0: DEVICE="eth0" BOOTPROTO="none" TYPE="OVSPort" DEVICETYPE="ovs" OVS_BRIDGE="br-ex" ONBOOT="yes" Steps to Reproduce: 1. Install the Havana release of RDO. 2. Launch an instance with the default configuration. 3. Open console to instance. 4. Run 'ping' to some IP address outside of the internal/fixed network. Actual results: Ping fails. Expected results: Ping succeeds. Additional info:
For an all-in-one setup, external network connectivity can also be achieved via NAT from br-ex to the external interface (which may be more palatable than actually making the external interface a member of br-ex). In any case, I agree that the documentation does need updates to address external connectivity. I would also argue that packstack should have an option for automating this part of the process.
I thought we had added this feature to packstack at some point, but a couple of test runs just now on F21 and CentOS 7 confirms that packstack still leaves the system without external network connectivity. Is this something we plan to fix, or is this *just* a documentation issue?
With an install on F21 using openstack-packstack-2014.2-0.18.dev1462.gbb05296.fc22.noarch, this (using the NAT solution) actually did the right thing: -P POSTROUTING ACCEPT -A POSTROUTING -j neutron-openvswi-POSTROUTING -A POSTROUTING -j neutron-postrouting-bottom -A POSTROUTING -s 172.24.4.224/28 -o eth0 -m comment --comment "000 nat" -j MASQUERADE -A POSTROUTING -j nova-api-POSTROUTING -A POSTROUTING -j nova-postrouting-bottom So I'm going to call this resolved.