Bug 1400703

Summary:	When Configuring Manila, the TripleO Heat Templates Will Not Configure the Required Default Share Type
Product:	Red Hat OpenStack	Reporter:	Dustin Schoenbrun <dschoenb>
Component:	openstack-tripleo-heat-templates	Assignee:	Jan Provaznik <jprovazn>
Status:	CLOSED ERRATA	QA Contact:	Dustin Schoenbrun <dschoenb>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	10.0 (Newton)	CC:	dschoenb, jjoyce, jprovazn, mburns, rhel-osp-director-maint, scohen, tbarron
Target Milestone:	z3	Keywords:	Triaged, ZStream
Target Release:	10.0 (Newton)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openstack-tripleo-heat-templates-5.2.0-18.el7ost	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-06-28 14:44:12 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 Dustin Schoenbrun 2016-12-01 21:37:33 UTC

Description of problem:
Stemming from a conversation with the PTL of Manila, it is required that all deployments of Manila define a default share type to use when creating shares (and a share type is not specified in the share create request). Devstack upstream does this, but our installer does not configure a default share type for Manila to use.

Version-Release number of selected component (if applicable):
openstack-tripleo-heat-templates-5.1.0-5.el7ost.noarch

How reproducible:
Always

Steps to Reproduce:
1. Install Manila using OSP Director and the TripleO Heat Templates
2. Attempt to create a Manila share using the Manila CLI client (manila create NFS 1)
3. Note that the share goes into error status
4. Check the scheduler log on the controller node where Manila is installed and see that the create failed due to no share type being specified either in the request or as a default type in the Manila configuration.

Actual results:
A default share type is not created so any share creation request that does not explicitly declare a share type will fail.

Expected results:
The TripleO Heat Templates shall configure a default share type for Manila.

Additional info:
The requirement for requiring a share type on share creation stems from the fact that all Manila drivers support either the Driver Handles Share Servers (DHSS) = True or False mode. The only way use this information is through the share types which will specify which mode the user desires. So if no share type is given, Manila does not know which mode the user desires and the creation of the share fails. With a default type (or when a type is explicitly given in the creation request), the desired value of DHSS is known and the scheduler can act appropriately.

An easy way to work around this is to create a share type specifying minimally the DHSS mode that the Manila driver you're using supports and specifying this share type as the default share type in the manila.conf file. This is done in the [default] stanza by doing the following:

[default]
...
default_share_type = <name_of_share_type>
...

Comment 2 Jan Provaznik 2017-01-09 08:26:05 UTC

upstream patches:
https://review.openstack.org/#/c/416960/
https://review.openstack.org/#/c/416958/

Comment 10 Dustin Schoenbrun 2017-05-26 16:18:29 UTC

I was able to build an OSP-10 environment with the 2017-05-23.4 puddle with the openstack-tripleo-heat-templates-5.2.0-18.el7ost.noarch package and the Manila configuration file on each of the controller nodes has the default_share_type value specified as "default". I was able to create the share type successfully and was able to create a share without issue. Marking the bug as verified.

Comment 12 errata-xmlrpc 2017-06-28 14:44:12 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1585