Bug 1465382

Summary:	[UPDATES] ip6tables.service fails to start after uc update to 7.4 is rebooted
Product:	Red Hat OpenStack	Reporter:	Yurii Prokulevych <yprokule>
Component:	openstack-tripleo-heat-templates	Assignee:	mathieu bultel <mbultel>
Status:	CLOSED DUPLICATE	QA Contact:	Gurenko Alex <agurenko>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	11.0 (Ocata)	CC:	agurenko, ajohn, amuller, aschultz, augol, ccamacho, ihrachys, jslagle, lbezdick, mburns, mcornea, rhel-osp-director-maint, sasha
Target Milestone:	---	Keywords:	Triaged
Target Release:	11.0 (Ocata)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-28 13:38:26 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 Yurii Prokulevych 2017-06-27 10:43:11 UTC

Description of problem:
-----------------------

systemctl status ip6tables.service
● ip6tables.service - IPv6 firewall with ip6tables
   Loaded: loaded (/usr/lib/systemd/system/ip6tables.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2017-06-27 05:38:46 EDT; 57min ago
  Process: 679 ExecStart=/usr/libexec/iptables/ip6tables.init start (code=exited, status=1/FAILURE)
 Main PID: 679 (code=exited, status=1/FAILURE)

Jun 27 05:38:46 undercloud-0.redhat.local systemd[1]: Starting IPv6 firewall with ip6tables...
Jun 27 05:38:46 undercloud-0.redhat.local ip6tables.init[679]: ip6tables: Applying firewall rules: Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
Jun 27 05:38:46 undercloud-0.redhat.local ip6tables.init[679]: [FAILED]
Jun 27 05:38:46 undercloud-0.redhat.local systemd[1]: ip6tables.service: main process exited, code=exited, status=1/FAILURE
Jun 27 05:38:46 undercloud-0.redhat.local systemd[1]: Failed to start IPv6 firewall with ip6tables.
Jun 27 05:38:46 undercloud-0.redhat.local systemd[1]: Unit ip6tables.service entered failed state.
Jun 27 05:38:46 undercloud-0.redhat.local systemd[1]: ip6tables.service failed.


Version-Release number of selected component (if applicable):
-------------------------------------------------------------
iptables-services-1.4.21-18.el7.x86_64
openstack-tripleo-heat-templates-6.0.0-12.el7ost.noarch
openstack-tripleo-validations-5.5.0-1.el7ost.noarch
python-tripleoclient-6.1.0-6.el7ost.noarch
puppet-tripleo-6.3.0-12.el7ost.noarch
openstack-tripleo-common-6.0.0-8.el7ost.noarch
openstack-tripleo-puppet-elements-6.0.0-3.el7ost.noarch
openstack-tripleo-image-elements-6.0.0-2.el7ost.noarch
openstack-tripleo-ui-3.1.0-9.el7ost.noarch

Steps to Reproduce:
1. Install RHOS-11
2. Setup repos (rhos-release -P 11 -p 7.4-testing -r 7.4)
3. Update uc
4. Reboot uc

Actual results:
---------------
Service is failed

Comment 2 Emilien Macchi 2017-06-27 12:26:47 UTC

It sounds like an issue where IPtables (v6) tries to start while another process of IPtables (probably v4) is already managing the rules.

I've done a bit of research and it seems like TripleO already use --wait option when using IPtables, since the iptables 1.4.20 (we have 1.4.21 in RHEL 7.4):
https://github.com/puppetlabs/puppetlabs-firewall/blob/b0e45f8ca06874b500b65dd36ab1dd838aed5826/lib/puppet/provider/firewall/iptables.rb#L651-L657

Since you hit that at reboot, I think we need to change the iptables.init (in packaging) to start the process with --wait if possible, so we avoid a race condition where iptables starts in the same time as ip6tables.

At this stage, we should probably reach out IPtables maintainers to get their feedback.

Comment 3 Ihar Hrachyshka 2017-08-22 17:48:43 UTC

This is same as https://bugzilla.redhat.com/show_bug.cgi?id=1481207

Comment 4 Assaf Muller 2017-08-28 13:35:56 UTC

We discussed this on a Networking DFG triage call, we don't see anything we can do here but to ping on the dependent iptables RHBZ.

Comment 5 Assaf Muller 2017-08-28 13:38:26 UTC


*** This bug has been marked as a duplicate of bug 1460116 ***

Comment 6 Bob Fournier 2018-02-19 15:17:52 UTC

*** Bug 1463375 has been marked as a duplicate of this bug. ***