Bug 1379543

Summary:	Enable gdeploy to check if firewalld service is started before opening the ports.
Product:	Red Hat Gluster Storage	Reporter:	RamaKasturi <knarra>
Component:	gdeploy	Assignee:	Sachidananda Urs <surs>
Status:	CLOSED DUPLICATE	QA Contact:	RamaKasturi <knarra>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	rhgs-3.1	CC:	rhs-bugs, smohan, storage-qa-internal
Target Milestone:	---
Target Release:	---
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:	2016-09-27 06:04:38 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:

Description RamaKasturi 2016-09-27 05:41:57 UTC

Description of problem:
If user is using a  platform where firewalld service is started by default then gdeploy will open the ports with out any issues.In an environment like RHEV-H firewalld is not started by default and due to this gdeploy fails to open the ports. gdeploy should have a functionality to check if service started before it tries to open the ports.

Version-Release number of selected component (if applicable):
gdeploy-2.0-16.el7rhgs.noarch

How reproducible:
Always

Steps to Reproduce:
1. Install RHEV-H from ISO
2. Install ansible and gdeploy packages
3. Run robo.conf from one of the node.

Actual results:
gdeploy fails to open the firewalld ports since firewalld service is not started.

Expected results:
gdeploy should check if service is started before opening the ports.

Additional info:

Comment 2 Sachidananda Urs 2016-09-27 05:54:43 UTC

Kasturi, there is already a bug for this: https://bugzilla.redhat.com/show_bug.cgi?id=1362570 and fixed in latest release. Please review and mark this as duplicate, if it is hte same bug.

Comment 3 RamaKasturi 2016-09-27 06:04:38 UTC

Thanks sachi. I will close this bug.

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