Flavor requirements checks not working correctly for RAM

[Julie Pichon]

The RAM checks always pass because we're comparing GB against MB - the image minimum RAM is returned in GB while the flavour minimum RAM is returned in MB.

Steps to reproduce:
1. Create a new image and set its minimum requirement to 8GB disk, 8GB RAM.
2. Try to launch an instance and select the new image

Actual result:
3. Minimum flavour is set to m1.small even though

Expected result:
3. Flavour should be at least m1.large (using the devstack default flavours) since it offers 80GB disk/8,192 MB, m1.small should be disabled.

If you add some debug statements around the related code, you'll see we're comparing 8 against 512 / 2048 / etc.
https://github.com/openstack/horizon/blob/759e497b0d/horizon/static/horizon/js/horizon.quota.js#L99

[Julie Pichon (jpichon)]

I didn't check the details but I suspect this applies to the server side check in https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/instances/workflows/create_instance.py as well because I didn't get an error when I tried to launch the instance with m1.small anyway.

Interestingly it doesn't look like Nova checks the minimum requirements either, as it launched the image successfully (I had set these limits on a tiny cirros image that doesn't actually require them.)

[Santiago Baldassin (santiago-b-baldassin)]

Nice catch Julie!! A couple of comments...first of all, the flavor should not be displayed if it does not meet the minimum requirements, that was reported a before: https://bugs.launchpad.net/horizon/+bug/1116122. The problem is that instead of removing the flavor from the list we added javascript validation that, as you pointed out, is not properly working.

As for the nova validation, they are supposed to fail in this situation: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L597

From my point of view, instead of fixing the client side validation in horizon.quota.js, we should fix the Create instance view and do not include the flavor in the choice field if it does not meet the requirements.

I'll take a closer look to nova code to see why it is not failing

[Julie Pichon (jpichon)]

Because the user can change their image choice, I think disabling is fine and easier to follow than removing / adding flavours, rather than changing the content of the flavour dropdown menu.

[Santiago Baldassin (santiago-b-baldassin)]

hmmm, I found it confusing to show an option when it's actually not eligible. From my point of view, a choice field should display "valid" choices
We've recently removed the non-bootable volumes from the boot source list in the same workflow and I think we should follow the same approach.

[Liz Blanchard (lblanchard)]

So I think it would be great if the flavor dropdown options could be responsive based on the image selection. Perhaps Flavor should be selected after selecting boot source? I do think it would be great to show all of the options in the flavor dropdown and just gray out and explain to the user why they can't select the smaller flavors in these cases.

[Itxaka Serrano (itxaka)]

Cant reproduce this on master/Liberty/Juno.

Marking as invalid.

[Itxaka Serrano (itxaka)]

Also cant reproduce in Kilo.

[Launchpad Janitor (janitor)]

[Expired for OpenStack Dashboard (Horizon) because there has been no activity for 60 days.]