Bug 1038255

Summary: prescript.pp does not ensure iptables-services package installation
Product: [Community] RDO Reporter: Gabriele Cerami <gcerami>
Component: openstack-puppet-modulesAssignee: Martin Magr <mmagr>
Status: CLOSED CURRENTRELEASE QA Contact: yeylon <yeylon>
Severity: urgent Docs Contact:
Priority: high    
Version: unspecifiedCC: itamar, Jan.van.Eldik, jeckersb, jlibosva, lars, mmagr, p, srevivo, whayutin, yeylon
Target Milestone: ---Keywords: Reopened
Target Release: Icehouse   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openstack-packstack-2014.1.1-0.8.dev1045 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-30 23:06:25 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:
Attachments:
Description Flags
logs of the failing jenkins job none

Description Gabriele Cerami 2013-12-04 17:50:20 UTC 
Description of problem:

In Fedora 19, iptables.service file for systemd is provided by a separate package iptables-services that is not installed by default.
prescript.pp puppet module in packstack tries to ensure that the iptables service is run without ensuring iptables-services package installation.

Version-Release number of selected component:
Version     : 2013.2.1
Release     : 0.17.dev876.fc20

How reproducible:
Bug should be reproducible on any bare install

Steps to Reproduce:
1. install base fedora system
2. install and run packstack

Actual results:
Error: Could not start Service[iptables]: Execution of '/sbin/service iptables start' returned 6: 
Error: /Stage[main]//Service[iptables]/ensure: change from stopped to running failed: Could not start Service[iptables]: Execution of '/sbin/service iptables start' returned 6: 


Expected results:
No errors

Additional info
If I issue the command directly:

[root@localhost ~]# /sbin/service iptables start
Redirecting to /bin/systemctl start  iptables.service
Failed to issue method call: Unit iptables.service failed to load: No such file or directory. See system logs and 'systemctl status iptables.service' for details.
Comment 1 Gabriele Cerami 2013-12-04 17:58:48 UTC 
Created attachment 832795 [details]
logs of the failing jenkins job
Comment 2 John Eckersberg 2013-12-18 17:13:54 UTC 
+1 from me, I just hit this same issue and came to file a new bug until I saw this one
Comment 3 Martin Magr 2014-01-06 17:20:57 UTC 
Packstack does not start iptables service anymore so this bug is not relevant anymore.
Comment 4 Pádraig Brady 2014-04-08 09:04:34 UTC 
Reopening as seen with openstack-packstack-puppet-2014.1.1-0.10.dev1045.el7.noarch

New firewall support might not be just a matter of a package dependency,
as I also see in the logs of bug 1040021, that `service iptables save` is no longer supported:

Notice: /Stage[main]/Quickstack::Swift::Proxy/Firewall[001 swift proxy incoming]/ensure: created
Warning: Firewall[001 swift proxy incoming](provider=iptables): Unable to persist firewall rules: Execution of '/sbin/service iptables save' returned 2: The service command supports only basic LSB actions (start, stop, restart, try-restart, reload, force-reload, status). For other actions, please try to use systemctl.
Comment 5 Pádraig Brady 2014-04-08 09:06:02 UTC 
This could impact Havana also for Fedora 20?
Comment 6 Lars Kellogg-Stedman 2014-04-08 13:21:22 UTC 
I think this is the same bug reported (and fixed) upstream here:

https://github.com/puppetlabs/puppetlabs-firewall/pull/338

For Fedora 19, the Puppet modules should already be trying to use /usr/libexec/initscripts/legacy-actions/iptables/save instead of "/sbin/service iptables save" (although prior to the above fixed, the necessary packages were not installed to make this work).

I will take a closer look at an F19 deployment today.
Comment 7 Jakub Libosvar 2014-04-08 14:16:17 UTC 
*** Bug 1085222 has been marked as a duplicate of this bug. ***
Comment 8 Martin Magr 2014-04-08 14:24:47 UTC 
It is not. Patch causing this has been merged only in master branch.
Comment 9 Martin Magr 2014-04-08 15:38:51 UTC 
Created PR for o-p-m: https://github.com/redhat-openstack/openstack-puppet-modules/pull/13