user unable to read flavor list without admin role

[Bharath]

Hi,

I have created 20 VMs from a snapshot, each user login is associated to an individual project and this project is added to the custom flavor i have created, the requirement was to ensure these users don't see each other's VMs, after launching the image the instances were accessible on the launch of 20th VM it started throwing error at Instance view as below

Error: Unable to retrieve instance size information.

On drill down of the instance: Error: Unable to retrieve details for instance "77521784-86a1-40e0-a083-ad0b560779dc

below are the traces i found in Apache2 log, nova-api log and finally keystone where it said the user needs Admin access to read the flavor which is unusual as the project to which the user is associated is already included in the flavor access list, this was reproducible after creating 20th VM or later in different projects.

Apache Horizon error:
[Mon Sep 08 15:21:21.969164 2014] [:error] [pid 5945:tid 140202637772544] NotFound: The resource could not be found. (HTTP 404) (Request-ID: req-c10869e3-81ea-4f2a-b6c3-9026cceaf43e)

Nova-api:
2014-09-08 20:51:21.869 2643 INFO nova.osapi_compute.wsgi.server [req-a4cdad89-047e-4451-85ed-caff08efb5f7 3f1474d0b016486c869e488b048ef5bb ab48d34b800545019fae208a43d8c254] 172.31.100.103 "GET /v2/ab48d34b800545019fae208a43d8c254/flavors/detail HTTP/1.1" status: 200 len: 704 time: 0.0101700
2014-09-08 20:51:21.967 2643 INFO nova.api.openstack.wsgi [req-c10869e3-81ea-4f2a-b6c3-9026cceaf43e 3f1474d0b016486c869e488b048ef5bb ab48d34b800545019fae208a43d8c254] HTTP exception thrown: The resource could not be found.

Keystone error:
2014-09-08 20:41:45.346 46413 WARNING keystone.common.wsgi [-] You are not authorized to perform the requested action, admin_required.

[Davanum Srinivas (DIMS) (dims-v)]

Is this devstack against trunk? or a released version of openstack?

[evanjfraser (evanjfraser)]

Hi there,
I'm not the submitter, but I'm having this problem with Icehouse on Fedora 20 with RDO version 2014.1.1-1.fc20.

Cheers, Evan.

[evanjfraser (evanjfraser)]

I've worked around the problem for now by:

Checking what the instance_type_id for those VM's is in the nova.instances DB table,
Then I set the is_public field to 1 for that instance_type in the nova.instance_types table.

Thanks, Evan.

[Bharath (bharathbharadwaj)]

This is Icehouse release, manual deployment not devstack.

[Bharath (bharathbharadwaj)]

I checked out the nova database, instances and instance_types tables, the instances active vm's had wrong instance_type_id values, the value it had when checked the same at instance_types table it was a deleted flavor, not sure why there are so many deleted flavors, also it seems to represent foreign keys, could this have happened due to name duplication as i deleted and recreated same username but this again shouldn't have happened.

Workaround was i updated the instance_type_id with the live flavor that is not deleted and immediately started to work.

[Bharath (bharathbharadwaj)]

Update: updating a flavor creates a new row with +1 incremented value for the column "id" and old record is marked as deleted, when this happens the instance's instance type id remains the same and the problem starts. Wondering what is the logic behind maintaining a version history and who is supposed to update the instance's type id?

[Markus Zoeller (markus_z) (mzoeller)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY