Bug 1103315 - Openstack firewall rules are not enabled after reboot
Summary: Openstack firewall rules are not enabled after reboot
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-foreman-installer
Version: 5.0 (RHEL 7)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ga
: Installer
Assignee: Jason Guiditta
QA Contact: Nir Magnezi
URL:
Whiteboard:
Depends On: 981583 981652 1099840
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-05-30 17:41 UTC by Mike Burns
Modified: 2014-08-21 18:04 UTC (History)
21 users (show)

Fixed In Version: openstack-foreman-installer-2.0.3-1.el6ost
Doc Type: Bug Fix
Doc Text:
Clone Of: 1099840
Environment:
Last Closed: 2014-08-21 18:04:13 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1090 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform Enhancement Advisory 2014-08-22 15:28:08 UTC
OpenStack gerrit 96511 None None None Never

Description Mike Burns 2014-05-30 17:41:17 UTC
Since linked fix is in packstack, we need an equivalent fix in OFI for use with OFI and staypuft.

+++ This bug was initially created as a clone of Bug #1099840 +++

+++ 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):
openstack-packstack-2013.1.1-0.3.dev527.fc19.noarch

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 ---

--- Additional comment from Miguel Angel Ajo on 2014-05-21 06:38:53 EDT ---

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?

--- Additional comment from Ihar Hrachyshka on 2014-05-21 06:46:13 EDT ---

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.

--- Additional comment from Lars Kellogg-Stedman on 2014-05-21 10:31:50 EDT ---

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.

--- Additional comment from Ihar Hrachyshka on 2014-05-21 10:40:23 EDT ---

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.

--- Additional comment from Miguel Angel Ajo on 2014-05-22 07:21:11 EDT ---

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.

--- Additional comment from Alvaro Lopez Ortega on 2014-05-29 13:08:17 EDT ---

Patch under review: https://review.openstack.org/#/c/96511/

--- Additional comment from Alvaro Lopez Ortega on 2014-05-30 10:14:26 EDT ---

Comment 1 Jason Guiditta 2014-05-30 21:59:03 UTC
Patch posted:

https://github.com/redhat-openstack/astapor/pull/244

Comment 2 Jason Guiditta 2014-06-02 14:18:14 UTC
Merged

Comment 3 Jason Guiditta 2014-06-03 17:18:15 UTC
Additional patch, 

https://github.com/redhat-openstack/astapor/pull/250

Commit message:
There was an additional issue where iptables rules were attempted to be
persisted before the service had been started. We need to make sure we call the
base firewall class on our side, which is what this patch does, and then once the
firewall module gets the fix needed on that side[1], everything should work more
cleanly.

[1] puppetlabs/puppetlabs-firewall#367

Comment 15 Mike Burns 2014-08-12 13:47:35 UTC
moving back to OFI.  This is the same issue as packstack, but needs to be verified using OFI/RHEL-OSP Installer

Comment 16 Alexander Chuzhoy 2014-08-12 13:57:19 UTC
Verified:rhel-osp-installer-0.1.9-1.el6ost.noarch

after the reboot, all the iptables rules are in place.

Comment 18 errata-xmlrpc 2014-08-21 18:04:13 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/RHBA-2014-1090.html


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