Red Hat Bugzilla – Bug 981144
need to set net.bridge.bridge-nf-call-iptables=1 for --allinone installation
Last modified: 2013-12-19 19:12:45 EST
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
(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).
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
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.
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.
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).
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