Bug 1304104 - Packstack Provides Nova Flavor ID that is Not Big Enough for Service Image
Packstack Provides Nova Flavor ID that is Not Big Enough for Service Image
Status: CLOSED ERRATA
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-packstack (Show other bugs)
8.0 (Liberty)
Unspecified Unspecified
unspecified Severity high
: ga
: 8.0 (Liberty)
Assigned To: Ivan Chavero
yeylon@redhat.com
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-02 16:54 EST by Dustin Schoenbrun
Modified: 2016-04-18 02:57 EDT (History)
5 users (show)

See Also:
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 17:27:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
OpenStack gerrit 276073 None None None 2016-02-04 02:15 EST

  None (edit)
Description Dustin Schoenbrun 2016-02-02 16:54:49 EST
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 01:16:13 EST
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 12:35:17 EST
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 10:43:47 EST
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 17:27:28 EDT
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

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