Description of problem: Packstack does not provision the appropriate firewall rules to allow access to the Quantum API from other hosts. The quantum server listens on port 9696. Given a configuration file that includes: CONFIG_QUANTUM_SERVER_HOST=192.168.122.199 CONFIG_NOVA_COMPUTE_HOSTS=192.168.122.76 On 192.168.122.199, after a successful server install, I see: # iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited But on 192.168.122.76, the compute host, I see: # iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -s 192.168.122.34/32 -p tcp -m multiport --dports 5900:5999 -m comment --comment "001 nova compute incoming 192.168.122.34" -j ACCEPT -A INPUT -s 192.168.122.199/32 -p tcp -m multiport --dports 9696 -m comment --comment "001 quantum incoming 192.168.122.199" -j ACCEPT -A INPUT -s 192.168.122.76/32 -p tcp -m multiport --dports 9696 -m comment --comment "001 quantum incoming 192.168.122.76" -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited The quantum firewall rules appear to be provisioned on the wrong host. And indeed, in manifests/192.168.122.76_quantum.pp I see: # Create firewall rules to allow only the hosts that need to connect # to quantum $hosts = [ '192.168.122.199','192.168.122.76' ] define add_allow_host { firewall { "001 quantum incoming ${title}": proto => 'tcp', dport => ['9696'], action => 'accept', source => $title, } } add_allow_host { $hosts:} This should be in manifests/192.168.122.199_quantum.pp. Version-Release number of selected component (if applicable): openstack-packstack-2013.1.1-0.33.dev695.el6ost.noarch
I ran into this same issue with a havana RDO packstack install. This breaks multi-node installs completely, and should be fixed in the next async releases for all versions of packstack that it effects.
*** Bug 1023979 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2013-1859.html