Bug 1400703 - When Configuring Manila, the TripleO Heat Templates Will Not Configure the Required Default Share Type
Summary: When Configuring Manila, the TripleO Heat Templates Will Not Configure the Re...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: z3
: 10.0 (Newton)
Assignee: Jan Provaznik
QA Contact: Dustin Schoenbrun
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-01 21:37 UTC by Dustin Schoenbrun
Modified: 2017-06-28 14:44 UTC (History)
7 users (show)

Fixed In Version: openstack-tripleo-heat-templates-5.2.0-18.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-28 14:44:12 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1654204 0 None None None 2017-01-05 10:37:23 UTC
OpenStack gerrit 418333 0 None None None 2017-02-08 13:06:30 UTC
OpenStack gerrit 423405 0 None None None 2017-02-08 13:02:59 UTC
Red Hat Product Errata RHBA-2017:1585 0 normal SHIPPED_LIVE Red Hat OpenStack Platform 10 director Bug Fix Advisory 2017-06-28 18:42:51 UTC

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


Note You need to log in before you can comment on or make changes to this bug.