Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

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-templatesAssignee: 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. ***