Bug 1023561 - Packstack provisions quantum firewall rules on the wrong host
Summary: Packstack provisions quantum firewall rules on the wrong host
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-packstack
Version: 3.0
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: beta
: 4.0
Assignee: Ivan Chavero
QA Contact: Ofer Blaut
URL:
Whiteboard: network
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-25 18:47 UTC by Lars Kellogg-Stedman
Modified: 2013-12-20 00:32 UTC (History)
8 users (show)

Fixed In Version: openstack-packstack-2013.2.1-0.8.dev835.el6ost
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-12-20 00:32:36 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 54399 0 None None None Never
Red Hat Product Errata RHEA-2013:1859 0 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform Enhancement Advisory 2013-12-21 00:01:48 UTC

Description Lars Kellogg-Stedman 2013-10-25 18:47:41 UTC
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

Comment 2 Bob Kukura 2013-10-25 19:29:20 UTC
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.

Comment 3 Ofer Blaut 2013-10-29 11:02:15 UTC
*** Bug 1023979 has been marked as a duplicate of this bug. ***

Comment 7 errata-xmlrpc 2013-12-20 00:32:36 UTC
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


Note You need to log in before you can comment on or make changes to this bug.