Bug 1408926

Summary:	Isolate the sections on enabling ssl and volume creation in gdeploy to prevent the volume mount problem.
Product:	[Red Hat Storage] Red Hat Gluster Storage	Reporter:	RamaKasturi <knarra>
Component:	gdeploy	Assignee:	Sachidananda Urs <surs>
Status:	CLOSED WONTFIX	QA Contact:	SATHEESARAN <sasundar>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	rhgs-3.2	CC:	amukherj, bmohanra, rcyriac, rhs-bugs, sabose, sasundar, smohan, storage-qa-internal, surs
Target Milestone:	---	Keywords:	ZStream
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Known Issue
Doc Text:	Currently the "ssl_enable" option is part of the "volume" section. It is a site wide change. If more than one volume is used in the same configuration (and within the same set of servers) and ssl_enable is set in all the volume sections, then the ssl operation steps are performed multiple times. This causes the older volumes to fail to mount. Users will then not be able to set SSL automatically with a single line of configuration. Workaround: If there are more than one volume on a node. Set the variable "enable_ssl" under one [volume] section and set the keys: 'client.ssl', value: 'on'; 'server.ssl', value: 'on';'auth.ssl-allow', value: <comma separated ssl hosts>	Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-11-08 12:57:33 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:
Bug Depends On:
Bug Blocks:	1351530

Description RamaKasturi 2016-12-28 07:46:03 UTC

Description of problem:
Currently to enable ssl on a volume using gdeploy the following flow has been followed.

1) creates a volume
2) set volume options
3) starts the volume
4) Generate private key
5) Generate self-signed-certificates
6) Copy the signed certificate to localhost
7) Create CA file on servers
8) Enable management encryption
9) stop the volume
10) Set volume options for SSL
11) Restart glusterd
12) start the volume

With the above flow if there is single volume in the cluster all works well. If there are multiple volumes in the cluster, same flow is repeated thrice and user will be able to mount only the volume which is created at the last. The other two volumes will be using old certificates and user will not be able to mount them.
Currently in HC setup we have three volumes which needs to be created and once gdeploy finishes creating volumes, user will not be able to mount the other volumes and because of this installation does not proceed and it fails.

It would be good to have a different section for enabling ssl so that the process is not repeated and setting volume options can be done in the volume creation itself.

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

How reproducible:
Always

Steps to Reproduce:
1. Use gdeploy to enable ssl on more than one volume in the cluster.
2.
3.

Actual results:
User will be able to mount only the last volume and volumes created before this he would not be able to mount.

Expected results:
User should be able to mount all the volumes and isolate enabling ssl and volume creation sections in gdeploy.

Additional info:

Comment 2 RamaKasturi 2016-12-28 07:47:44 UTC

put blocker '?' because when volumes are created using gdeploy with ssl_enabled, mounting of volume does not work and due to his hc installation fails.

Comment 3 SATHEESARAN 2016-12-28 08:23:20 UTC

Also the workflow goes like this when the volume requires encryption:

1. Create volume
2. Set volume options ( if provided as part of [volume] gdeploy ansible module )
3. Start the volume
4. If encryption is required on the volume, ssl options ( server.ssl=on & client.ssl=on) are set on the volume
5. Stop & Start the volume

In the above workflow the volume goes through start->stop->start states.

The corrected workflow could be:
1. Create volume
2. Set volume options ( if provided as part of [volume] gdeploy ansible module )
3. If encryption is required on the volume, SSL volume options ( server.ssl=on & client.ssl=on) are set on the volume
4. Start the volume

With the corrected workflow, there is only one volume start and reduces the gdeploy configuration time.

Comment 5 Sachidananda Urs 2016-12-29 07:20:53 UTC

(In reply to SATHEESARAN from comment #3)
> Also the workflow goes like this when the volume requires encryption:
> 
> 1. Create volume
> 2. Set volume options ( if provided as part of [volume] gdeploy ansible
> module )
> 3. Start the volume
> 4. If encryption is required on the volume, ssl options ( server.ssl=on &
> client.ssl=on) are set on the volume
> 5. Stop & Start the volume
> 
> In the above workflow the volume goes through start->stop->start states.
> 
> The corrected workflow could be:
> 1. Create volume
> 2. Set volume options ( if provided as part of [volume] gdeploy ansible
> module )
> 3. If encryption is required on the volume, SSL volume options (
> server.ssl=on & client.ssl=on) are set on the volume
> 4. Start the volume
> 
> With the corrected workflow, there is only one volume start and reduces the
> gdeploy configuration time.

sas, the volume stop-start is added because we support ssl setup on existing
volumes as well. And we try to stop first to ensure we don't do anything on
running volumes.

Comment 7 SATHEESARAN 2017-02-10 05:58:16 UTC

Currently gdeploy follows the 3 step process when enabled per volume
1. Creation of SSL files ( glusterfs.key, glusterfs.pem, glusterfs.ca )
2. Enabling SSL with glusterd 
3. Enabling SSL on that gluster volume

The above 3 steps are done together when the volume section has 'enable_ssl=yes' and 'ssl_clients=host1,host2'

So, the above 3 steps should not be done together as it may contradict the some case. Take for instance, when expanding the cluster, user may just require to generate SSL cert files on the new host and turn on SSL for glusterd but not on the volume, as the volume would have already enabled SSL

In other case, he may have the SSL certs creating by his own ( say there is a CA available ), in that case the user may just want to turn on SSL on glusterd and volumes, but not to generate SSL cert files once again.

Gdeploy should consider all these cases and provide the flexibility to handle above mentioned cases

Comment 13 Sachidananda Urs 2018-10-22 05:37:53 UTC

Since this functionality will be moved to gluster-ansible in future, this bug is flagged for closure. If there is a requirement to fix in 3.x please update the bug.

Comment 14 Atin Mukherjee 2018-11-08 12:48:46 UTC

But is there any need to have this bug kept open here?

Comment 15 Sachidananda Urs 2018-11-08 12:57:33 UTC

If there were any requirements to fix this in 3.x updates; I was expecting a comment here. Now that I don't see anyone commenting from past two weeks, we can close this.