Running OpenStack IceHouse.

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 |
+-----------------------------+-------+
| instances                   | 0     |
| cores                       | 0     |
| ram                         | 0     |
| floating_ips                | 0     |
| fixed_ips                   | 0     |
| metadata_items              | 0     |
| injected_files              | 0     |
| injected_file_content_bytes | 0     |
| injected_file_path_bytes    | 0     |
| key_pairs                   | 0     |
| security_groups             | 0     |
| security_group_rules        | 0     |
+-----------------------------+-------+

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 |
+-----------------------------+-------+
| instances                   | 10    |
| cores                       | 20    |
| ram                         | 65536 |
| floating_ips                | 5     |
| fixed_ips                   | -1    |
| metadata_items              | 128   |
| injected_files              | 5     |
| injected_file_content_bytes | 10240 |
| injected_file_path_bytes    | 255   |
| key_pairs                   | 100   |
| security_groups             | 10    |
| security_group_rules        | 20    |
+-----------------------------+-------+

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.