Bug 981144 - need to set net.bridge.bridge-nf-call-iptables=1 for --allinone installation
Summary: need to set net.bridge.bridge-nf-call-iptables=1 for --allinone installation
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-packstack
Version: 3.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: Upstream M3
: 4.0
Assignee: RHOS Maint
QA Contact: Nir Magnezi
URL:
Whiteboard:
Depends On:
Blocks: 981469 997941
TreeView+ depends on / blocked
 
Reported: 2013-07-04 06:30 UTC by Etsuji Nakai
Modified: 2013-12-20 00:12 UTC (History)
9 users (show)

Fixed In Version: openstack-packstack-2013.2.1-0.3.dev722.el6ost
Doc Type: Bug Fix
Doc Text:
Cause: Kernel parameters were not correctly set during packstack installation due to interfering puppet processes. Consequence: Security groups did not function and parameters were not set at boot time. Fix: Interfering puppet processes are disabled and the following kernel parameters are now set in /etc/sysctl.conf: net.bridge.bridge-nf-call-ip6tables=1 net.bridge.bridge-nf-call-iptables=1 net.bridge.bridge-nf-call-arptables=1 Result: Installation now operates as expected due to kernel parameters being set successfully.
Clone Of:
: 981469 997941 (view as bug list)
Environment:
Last Closed: 2013-12-20 00:12:45 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 36835 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 Etsuji Nakai 2013-07-04 06:30:21 UTC
Document URL: 
https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/3/html-single/Getting_Started_Guide/index.html#sect-Quick_Start_Deployment_using_PackStack

Section Number and Name: 
4.1. Quick Start Deployment using PackStack

Describe the issue: 
For the single node deployment with "packstack --allinone", following kernel parms should be set so that the security group works correctly.

net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 1

Suggestions for improvement: 

Add the following steps after "packstack --allinone".

1) Create the following script to load bridge module at boottime. (Without this, settings in /etc/sysctl.conf cannot be applied at boottime.)

/etc/sysconfig/modules/openstack-quantum.modules 
-----------------
#!/bin/sh
modprobe -b bridge >/dev/null 2>&1
exit 0
-----------------

2) Set the following in /etc/sysctl.conf
-----------------
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 1
-----------------

Additional information: 

# rpm -qa | grep packstack
openstack-packstack-2013.1.1-0.20.dev632.el6ost.noarch

# rpm -qa | grep quantum
openstack-quantum-openvswitch-2013.1.2-3.el6ost.noarch
python-quantum-2013.1.2-3.el6ost.noarch
openstack-quantum-2013.1.2-3.el6ost.noarch
python-quantumclient-2.2.1-1.el6ost.noarch

Comment 2 Stephen Gordon 2013-07-04 20:25:25 UTC
(In reply to Etsuji Nakai from comment #0)
> Describe the issue: 
> For the single node deployment with "packstack --allinone", following kernel
> parms should be set so that the security group works correctly.
> 
> net.bridge.bridge-nf-call-ip6tables = 1
> net.bridge.bridge-nf-call-iptables = 1
> net.bridge.bridge-nf-call-arptables = 1

If this is actually the case I think the correct approach is to update PackStack to handle this, not document around it (though if these steps are required I am sure we will need to cover it in the other guide for users performing manual setup).

Comment 6 Nir Magnezi 2013-10-17 07:29:51 UTC
Reopened.

Used openstack-packstack-2013.2.1-0.6.dev763.el6ost.noarch to install openstack:

# packstack --allinone -d


Result:
=======
# grep nf-call- /etc/sysctl.conf 
net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-iptables=0
net.bridge.bridge-nf-call-arptables=0

Comment 8 Martin Magr 2013-10-17 10:44:11 UTC
From logs it looks OK:
[0;36mnotice: /Stage[main]/Packstack::Neutron::Bridge/File_line[/etc/sysctl.conf bridge-nf-call-ip6tables]/ensure: created[0m
[0;36mnotice: /Stage[main]/Packstack::Neutron::Bridge/File_line[/etc/sysctl.conf bridge-nf-call-iptables]/ensure: created[0m
[0;36mnotice: /Stage[main]/Packstack::Neutron::Bridge/File_line[/etc/sysctl.conf bridge-nf-call-arptables]/ensure: created[0m

And from my RDO testing:   
[para@virtual-rhel ~]$ cat /etc/sysctl.conf | grep "net.bridge"
net.bridge.bridge-nf-call-ip6tables=1
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-arptables=1
[para@virtual-rhel ~]$ rpm -q openstack-packstack
openstack-packstack-2013.2.1-0.10.dev763.el6.noarch

Will try also ost version, but since these packages are made from the same tarball I think it should not be different.

Comment 9 Martin Magr 2013-10-17 11:36:59 UTC
So indeed it's the same for ost package:

[para@virtual-rhel ~]$ cat /etc/sysctl.conf | grep "net.bridge" ; rpm -q openstack-packstack
net.bridge.bridge-nf-call-ip6tables=1
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-arptables=1
openstack-packstack-2013.2.1-0.6.dev763.el6ost.noarch
[para@virtual-rhel ~]$ 

I guess we are missing something here. I even tried to reboot (in case this is changed in boot time somehow), but the values stayed the same.

Comment 10 Nir Magnezi 2013-10-20 12:23:21 UTC
Verified NVR: openstack-packstack-2013.2.1-0.6.dev763.el6ost.noarch

It seems like non packstack puppet processes, affected the configuration.
I disabled them and the values in /etc/sysctl.conf look OK now (tested several times).

Comment 13 errata-xmlrpc 2013-12-20 00:12:45 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.