Bug 1099840 - Openstack firewall rules are not enabled after reboot [NEEDINFO]
Summary: Openstack firewall rules are not enabled after reboot
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-packstack
Version: 5.0 (RHEL 7)
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: 5.0 (RHEL 7)
Assignee: Ivan Chavero
QA Contact: Amit Ugol
: 1097435 (view as bug list)
Depends On: 981583 981652
Blocks: 1103315
TreeView+ depends on / blocked
Reported: 2014-05-21 10:37 UTC by Miguel Angel Ajo
Modified: 2014-09-08 05:43 UTC (History)
17 users (show)

Fixed In Version: openstack-packstack-2014.1.1-0.16.dev1100.el7ost
Doc Type: Bug Fix
Doc Text:
Clone Of: 981583
: 1103315 (view as bug list)
Last Closed: 2014-07-08 15:38:36 UTC
Target Upstream Version:
augol: needinfo? (ichavero)

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
OpenStack gerrit 96511 0 None None None Never
Red Hat Product Errata RHEA-2014:0846 0 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform Enhancement - Packstack 2014-07-08 19:23:14 UTC

Description Miguel Angel Ajo 2014-05-21 10:37:41 UTC
+++ This bug was initially created as a clone of Bug #981583 +++

Description of problem:
Firewall rules are applied by packstack via iptables, but in f19 the default firewall management tool is firewalld, this means that the rules are not persistent across reboot if firewalld is enabled.

Version-Release number of selected component (if applicable):

How reproducible:
Always if firewalld is enabled and iptables is not.

Steps to Reproduce:
1. run packstack
2. reboot

Actual results:
After the reboot "iptables -L" shows no packstack specific rules.

Expected results:
There should be firewall rules for openstack present after reboot.

Additional info:
This can be fixed by disabling/stopping the firewalld service and enabling/starting the iptables service.

--- Additional comment from Fedora Admin XMLRPC Client on 2013-10-14 05:50:53 EDT ---

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

--- Additional comment from Fedora Admin XMLRPC Client on 2013-10-14 05:51:39 EDT ---

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

--- Additional comment from Sandro Mathys on 2013-11-14 04:40:07 EST ---

--- Additional comment from Pádraig Brady on 2014-01-08 11:31:18 EST ---

I'm not sure we should depend on 981652.
Well ideally yes, but could we specifically handle this in packstack?
This is still an issue on Fedora 20.

--- Additional comment from Lars Kellogg-Stedman on 2014-01-15 10:17:46 EST ---

Comment 1 Miguel Angel Ajo 2014-05-21 10:38:53 UTC
This also fixes the issue, and leaves the packstack iptables working
after reboot:

# yum remove firewalld
# reboot

May be we should just add this step to packstack scripts?

Comment 2 Ihar Hrachyshka 2014-05-21 10:46:13 UTC
I'm against removing firewalld with packstack. Users should use default firewall service, there are good reasons why fedora and RHEL migrated to the new implementation.

Comment 3 Lars Kellogg-Stedman 2014-05-21 14:31:50 UTC
Note that at the time the original bug was filed there were also problems with the puppetlabs "firewall" module, which was not installing the necessary "iptables-services" package under Fedora (which provides legacy support of /etc/sysconfig/iptables).  This has since been fixed, and since both iptables-services and firewalld may be installed in parallel this may no longer be an issue.

It would be nice if packstack worked with firewalld, but that will require substantial work with the puppetlabs "firewall" module, which currently has no support for firewalld.

Comment 4 Ihar Hrachyshka 2014-05-21 14:40:23 UTC
Thanks for the info.

My understanding is that Miguel cloned the bug to RHOSP5 because he had his firewall rules not applied after reboot until firewalld was disabled.

Comment 5 Miguel Angel Ajo 2014-05-22 11:21:11 UTC
Yes, in my case it's that. The firewall rules didn't get applied after reboot until firewalld was disabled/removed.

I'm with you Ihar, that the final solution may be supporting firewalld correctly, but if that's not possible in the short term, may be removing/disabling firewalld in the meanwhile could be acceptable.

Comment 6 Alvaro Lopez Ortega 2014-05-29 17:08:17 UTC
Patch under review: https://review.openstack.org/#/c/96511/

Comment 7 Alvaro Lopez Ortega 2014-05-30 14:14:26 UTC
*** Bug 1097435 has been marked as a duplicate of this bug. ***

Comment 8 Ivan Chavero 2014-06-01 00:32:25 UTC
Fixed in new package  openstack-puppet-modules-2014.1-13.1.el7ost

Comment 9 Ivan Chavero 2014-06-02 18:13:51 UTC
sorry i pasted the wrong package, fixed in: openstack-packstack-2014.1.1-0.16.dev1100.el7ost

Comment 10 Amit Ugol 2014-06-17 08:49:49 UTC
Seems to be fine on my tested server which I installed with these versions:

# cat system-release
Red Hat Enterprise Linux Server release 7.0 (Maipo)

# rpm -qa | grep "openstack-packstack\|openstack-puppet" | sort

After installation:
# systemctl status firewalld
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled)
   Active: inactive (dead)

However I do not understand if this is the path to close this issue or just a stepping stone. If the latter, then I won't verify it until a final thing is implemented.

If however we want to see this working now and handle it at the next version, then its possible to verify and close this bug and open a new one for whichever version it will be closed in.

Comment 12 Amit Ugol 2014-06-25 09:44:08 UTC
no answer so I guess that I am closing it for now.

Comment 14 errata-xmlrpc 2014-07-08 15:38: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.


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