Bug 1438534

Summary:	split-stack: firewall not purged on initial deployment
Product:	Red Hat OpenStack	Reporter:	James Slagle <jslagle>
Component:	openstack-tripleo-heat-templates	Assignee:	James Slagle <jslagle>
Status:	CLOSED ERRATA	QA Contact:	Gurenko Alex <agurenko>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	11.0 (Ocata)	CC:	agurenko, jschluet, mburns, rhel-osp-director-maint, slinaber
Target Milestone:	rc	Keywords:	Triaged
Target Release:	11.0 (Ocata)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openstack-tripleo-heat-templates-6.0.0-4.el7ost	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-05-17 20:17:15 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description James Slagle 2017-04-03 16:54:42 UTC

As part of https://bugs.launchpad.net/tripleo/+bug/1657108, a bug was fixed where the initial firewall gets purged as part of the image build. This is needed because if you have by default REJECT rules in iptables, you can have problems with pacemaker initializing the cluster, see also https://bugs.launchpad.net/tripleo/+bug/1672216

We also need to perform the same purge steps in the deployed server bootstrap SoftwareConfig.

Comment 4 Gurenko Alex 2017-04-23 17:47:33 UTC

 Please disregard previous comment, it was wrongly posted. As of build 2017-04-20.2 this bug is still present.

[stack@undercloud-0 ~]$ rpm -q openstack-tripleo-heat-templates
openstack-tripleo-heat-templates-6.0.0-5.el7ost.noarch

Comment 5 Gurenko Alex 2017-04-23 17:53:03 UTC

I can see that following lines are present in deployed-server-bootstrap-rhel.sh

echo '# empty ruleset created by deployed-server bootstrap' > /etc/sysconfig/iptables
echo '# empty ruleset created by deployed-server bootstrap' > /etc/sysconfig/ip6tables

But unless manually executed on overcloud nodes, deployment does not move any further and fails after some time.

Comment 6 Gurenko Alex 2017-04-24 05:54:18 UTC

 I'm not sure what was happening yesterday, left 2 other deployments overnight both succeed. The only thing I did is executed fstrim on both servers prior to that. Marking it as verified for build 20.2

Comment 7 errata-xmlrpc 2017-05-17 20:17:15 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.

https://access.redhat.com/errata/RHEA-2017:1245