When Launching a new Instance, all flavors are displayed regardless of the image requirements

Bug #1116122 reported by Julie Pichon
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Dashboard (Horizon)
Fix Released
Matt Wagner

Bug Description

Regardless of an image's disk and RAM requirements, all flavors are available in the drop-down menu when Launching a new instance. Therefore you can end up using e.g. a m1.tiny flavour with 512Mb RAM with an image that requires at least 2Gb of RAM.

To reproduce:
1. Create a new image, setting the minimum RAM requirement to 2048MB
2. After the image is uploaded, try to Launch it

Actual results:
3. The flavor selected by default is m1.tiny, which doesn't actually provide enough RAM for the image.

After clicking Launch, the instance fails to launch with an error message "Error: There was an error submitting the form. Please try again." (* )

Expected results:
3. Horizon should default to an appropriate flavor, and probably prevent the user from launching an image with a flavor that doesn't meet the image's requirements.

The UI should also be enhanced to display the image's requirements. At the moment, there is no indication what an image's requirements are when launching a new instance.

(*) This was on a recent grizzly devstack. I also tested in a Folsom devstack and received a better error message back: "Instance type's memory is too small for requested image. (HTTP 400)". This is still visible in the logs - RESP BODY: {"badRequest": {"message": "Instance type's memory is too small for requested image.", "code": 400}}. It's unfortunate we appear to have lost the clearer error message along the way.

Changed in horizon:
status: New → Confirmed
Revision history for this message
Julie Pichon (jpichon) wrote :

Ah, with regard to the less useful error message, my local settings had the following in it (the devstack default):

    'dashboards': ('project', 'admin', 'settings',),
    'default_dashboard': 'project',

which overwrites the much more useful HORIZON_CONFIG in settings.py, and gets merged with the Horizon default config at https://github.com/openstack/horizon/blob/master/horizon/conf/default.py which has empty arrays for the exception types that are surfaced back.

Removing or updating the local settings' HORIZON_CONFIG got me the nicer error message back.

Changed in horizon:
importance: Undecided → Wishlist
Changed in horizon:
assignee: nobody → Matt Wagner (matt-wagner)
Revision history for this message
Matt Wagner (matt-wagner) wrote :

Just to clarify, I think there are really two separate enhancements proposed here:

1.) Show the minimums for an image, if present. (Minimum RAM, disk.)
2.) Disallow selection of flavors that don't meet those minimums.

I don't think it's either-or; we should ideally do both.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to horizon (master)

Fix proposed to branch: master
Review: https://review.openstack.org/31099

Changed in horizon:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to horizon (master)

Reviewed: https://review.openstack.org/31099
Committed: http://github.com/openstack/horizon/commit/e07e93a1d7bc7b4b42569518701bfe30be8f3b03
Submitter: Jenkins
Branch: master

commit e07e93a1d7bc7b4b42569518701bfe30be8f3b03
Author: Matt Wagner <email address hidden>
Date: Thu May 30 13:48:49 2013 -0400

    Disable selection of undersized flavors for image

    Where an image has minimum requirements for RAM or disk, we should
    not allow users to select a flavor that does not meet those
    requirements only to have the form fail when submitted.

    Change-Id: I00667f4ca30a43771eaf3257fd055d3387687658
    Fixes: bug 1116122

Changed in horizon:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in horizon:
milestone: none → icehouse-1
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in horizon:
milestone: icehouse-1 → 2014.1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.