flavor-access-add doesn't validate the tenant id

[Julie Pichon]

I can use a random string to represent the tenant when calling flavor-access-add, and it will be shown in the flavor-access-list output even though it has no meaning and won't work. This causes confusion for users, who use the command to add tenants by name and then wonder why they can't access the new flavour (e.g. bug 1083602, bug 1315479).

Steps to reproduce:

1. Create a private flavour

$ nova flavor-create --is-public false abcdef auto 1 1 1
+--------------------------------------+--------+-----------+------+-----------+------+-------+-------------+-----------+
| ID | Name | Memory_MB | Disk | Ephemeral | Swap | VCPUs | RXTX_Factor | Is_Public |
+--------------------------------------+--------+-----------+------+-----------+------+-------+-------------+-----------+
| f349c9a1-ce16-4511-9da0-eeced2f1baa4 | abcdef | 1 | 1 | 0 | | 1 | 1.0 | False |
+--------------------------------------+--------+-----------+------+-----------+------+-------+-------------+-----------+

2. Give access to a tenant by name

$ nova flavor-access-add f349c9a1-ce16-4511-9da0-eeced2f1baa4 demo

3. It looks like it was added correctly, but if I do 'nova flavor-list' with a user from the demo tenant it will not show the flavour.

$ nova flavor-access-list --flavor f349c9a1-ce16-4511-9da0-eeced2f1baa4
+--------------------------------------+-----------+
| Flavor_ID | Tenant_ID |
+--------------------------------------+-----------+
| f349c9a1-ce16-4511-9da0-eeced2f1baa4 | demo |
+--------------------------------------+-----------+

The name doesn't need to exist at all, I can successfully add random strings:

$ nova flavor-access-add f349c9a1-ce16-4511-9da0-eeced2f1baa4 this-tenant-does-not-exist
+--------------------------------------+----------------------------+
| Flavor_ID | Tenant_ID |
+--------------------------------------+----------------------------+
| f349c9a1-ce16-4511-9da0-eeced2f1baa4 | demo |
| f349c9a1-ce16-4511-9da0-eeced2f1baa4 | this-tenant-does-not-exist |
+--------------------------------------+----------------------------+

I think we shouldn't allow invalid IDs when running "nova flavor-access-add".

[Thang Pham (thang-pham)]

I am hoping to get my blueprint accepted so that tenant/user IDs are validated through keystone: https://blueprints.launchpad.net/nova/+spec/validate-tenant-user-with-keystone. I have a similar problem with quota tenant/user IDs. I will be glad to handle this bug once the BP is accepted.

[Julie Pichon (jpichon)]

This looks promising, thanks!

[Thang Pham (thang-pham)]

abhishek-talwar: I am not sure why you re-assigned the bug to yourself, but I have a blueprint up for this waiting for approval - https://review.openstack.org/#/c/92507/

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

Are there any active reviews?

[Thang Pham (thang-pham)]

John Garbutt blocked non-high/critical features like this for kilo. It has to be pushed out to liberty.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Joe Gordon (<email address hidden>) on branch: master
Review: https://review.openstack.org/143934
Reason: This review is > 4 weeks without comment and currently blocked by a core reviewer with a -2. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and contacting the reviewer with the -2 on this review to ensure you address their concerns.

[Bruno Lago (teolupus)]

Running OpenStack IceHouse on Ubuntu 14.04.

I can confirm that if I do:

nova quota-update --instances 0 [...--all other things 0...] my-tenant-name

nova quota-show my-tenant-name

+-----------------------------+-------+
| Quota | Limit |
+-----------------------------+-------+
[...]
+-----------------------------+-------+

You can see that the quota update apparently works and I can even query the quota for my-tenant-name and get back the right results.

However, when I query the TENANT_ID that matches my tenant name, I see:

nova quota-show --tenant $TENANT_ID

+-----------------------------+-------+
| Quota | Limit |
+-----------------------------+-------+
[...]
+-----------------------------+-------+

The same is shown on the dashboard, and as expected, I can launch instances.

Looking at the quotas table in the database, in particular the tenant-id, we can see that OpenStack inserted the tenant name (my-tenant-name), instead the tenant-id in the tenant-id column.

mysql> select * from quotas;

| 3015 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | metadata_items | 1 | 0 |
| 3018 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | injected_file_content_bytes | 1 | 0 |
| 3021 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | ram | 1 | 0 |
| 3024 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | floating_ips | 1 | 0 |
| 3027 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | key_pairs | 1 | 0 |
| 3030 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | instances | 1 | 0 |
| 3033 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | injected_files | 1 | 0 |
| 3036 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | cores | 1 | 0 |
| 3039 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | fixed_ips | 1 | 0 |
| 3042 | 2015-07-30 03:40:33 | 2015-07-30 04:26:04 | NULL | my-tenant-name | injected_file_path_bytes | 1 | 0 |
| 3093 | 2015-07-30 03:43:28 | 2015-07-30 04:26:04 | NULL | my-tenant-name | security_group_rules | 1 | 0 |
| 3108 | 2015-07-30 03:43:28 | 2015-07-30 04:26:04 | NULL | my-tenant-name | security_groups | 1 | 0 |

The same applies to cinder and neutron.

In essence, the APIs and the command line tools should refuse to update quota for a tenant-id that does not exist, but are not doing so. As a result, you end up with some dodgy entries in the database and an apparently successful quota update that does not work.

[Vincent Legoll (vincent-legoll)]

I got bit by this bug on the "nova quota-update" front...

To fix the problems induced by this bug, I did the following:

# Connect to your openstack database (add the right parameters to do so)
$ mysql [...]
mysql> use nova;
mysql> # Have a look at the mess...
mysql> select * from quotas;
mysql> # Ensure that you're selecting the right set of bad rows
mysql> select * from quotas where project_id = "THE_TENANT_NAME";
mysql> # Nuke them all
mysql> delete from quotas where project_id = "THE_TENANT_NAME";