Bug 1304104

Summary:	Packstack Provides Nova Flavor ID that is Not Big Enough for Service Image
Product:	Red Hat OpenStack	Reporter:	Dustin Schoenbrun <dschoenb>
Component:	openstack-packstack	Assignee:	Ivan Chavero <ichavero>
Status:	CLOSED ERRATA	QA Contact:	yeylon <yeylon>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	8.0 (Liberty)	CC:	aortega, dschoenb, srevivo, tbarron, yeylon
Target Milestone:	ga
Target Release:	8.0 (Liberty)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openstack-packstack-7.0.0-0.13.dev1702.g490e674.el7ost	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-04-07 21:27:28 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-02-02 21:54:49 UTC

Description of problem:
When attempting to create a Manila share with the Generic Share Driver, the default Nova flavor ID does not provide a disk big enough for the Service Image to reside. This presents a problem as the host that facilitates the mounting of the Manila share does not boot correctly due to the error which causes the share to go into error status. By default, the Packstack answer file specifies the Nova Flavor ID as "1", specifying 512 MB of RAM and a 1 GB disk. For comparison, Devstack creates a new Nova flavor specifying 128 MB of RAM and a 0 GB disk (which is a special case where the size of the ephemeral root volume is set to the native base image's size). To solve this, we either need to use a different flavor that is provided by Nova as it is or we will need to create a new Nova flavor with appropriate parameters that is then specified in the Manila configuration file to use for the service instances.

Version-Release number of selected component (if applicable):
openstack-packstack-puppet-7.0.0-0.10.dev1684.g87ec498.el7ost.noarch
puppet-3.6.2-3.el7.noarch
openstack-puppet-modules-7.0.3-1.el7ost.noarch

How reproducible:
100%

Steps to Reproduce:
1. Setup and install Manila via Packstack
2. Create the required share network from the private Neutron network.
3. Create a default share type for Manila, specifying "driver_handles_share_servers" as True
4. Attempt to create a share specifying the correct share network
5. Observe that the share creation fails due to the share instance not starting correctly.

Actual results:
The share creation fails due to the service instance not booting correctly.

Expected results:
The share shall be created successfully.

Comment 2 Ivan Chavero 2016-02-03 06:16:13 UTC

If you change the flavor manually the share creation works?
If that's so, this does not looks like a bug.

Comment 3 Dustin Schoenbrun 2016-02-03 17:35:17 UTC

Yes, if you update the service_instance_flavor_id value in /etc/manila/manila.conf and then restart the Manila services the share creation will succeed due to the new Nova flavor specified. The issue is more of the fact that the default values provided by Packstack do not work out of the box. If we want to say that this is fine as is, but just requires a configuration change on the part of the user, then we need to be sure we document that somewhere, though I don't think that's the correct solution.

Comment 4 Dustin Schoenbrun 2016-02-08 15:43:47 UTC

One possible solution is to create a new Nova flavor specifically for the Manila Service Instance. The following command will create one equivalent to the Nova Flavor that Devstack uses:

nova flavor-create manila_service_flavor 100 128 0 1

Where "manila_service_flavor" is the name of the flavor,
100 is the ID of the flavor,
128 is the amount to RAM to give the instance in MB,
0 is the size of the root disk, which is a special cases where the flavor will use the native base image size as the size of the ephemeral root volume. Essentially it will make the size of the image as big as it needs to be, 
and 1 is the number of vCPUs to assign to the instance.

Hope this helps!

Comment 7 errata-xmlrpc 2016-04-07 21:27:28 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://rhn.redhat.com/errata/RHEA-2016-0603.html