| 2018-06-20 14:18:16 |
Lance Bragstad |
bug |
|
|
added bug |
| 2018-06-20 14:18:21 |
Lance Bragstad |
keystone: importance |
Undecided |
Medium |
|
| 2018-06-20 14:18:25 |
Lance Bragstad |
keystone: status |
New |
Triaged |
|
| 2018-06-20 14:20:44 |
Lance Bragstad |
description |
Unified limits consists of registered limits and limits, which are project-specific. Both types are isolated into separate database tables (keystone.registered_limit and keystone.limit).
Currently, the schema for keystone.registered_limit is:
mysql> describe keystone.registered_limit;
+---------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------------+--------------+------+-----+---------+-------+
| id | varchar(64) | NO | PRI | NULL | |
| service_id | varchar(255) | YES | MUL | NULL | |
| region_id | varchar(64) | YES | MUL | NULL | |
| resource_name | varchar(255) | YES | | NULL | |
| default_limit | int(11) | NO | | NULL | |
| description | text | YES | | NULL | |
+---------------+--------------+------+-----+---------+-------+
6 rows in set (0.00 sec)
The following is the schema for keystone.limit:
mysql> describe keystone.limit;
+----------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------+--------------+------+-----+---------+-------+
| id | varchar(64) | NO | PRI | NULL | |
| project_id | varchar(64) | YES | MUL | NULL | |
| service_id | varchar(255) | YES | MUL | NULL | |
| region_id | varchar(64) | YES | | NULL | |
| resource_name | varchar(255) | YES | | NULL | |
| resource_limit | int(11) | NO | | NULL | |
| description | text | YES | | NULL | |
+----------------+--------------+------+-----+---------+-------+
7 rows in set (0.00 sec)
There are some duplicated attributes between these two tables that are requirements for the API (e.g. a limit cannot be created without a corresponding limit being registered first). We have the opportunity to simplify the schema of the keystone.limit table by removing limit.service_id, limit.region_id, and limit.resource_name in favor of a single column called limit.registered_limit_id that maintains a FK relationship to a record in keystone.registered_limit.
The unified limit API will use the FK relationship to populate service_id, region_id, and resource_name attributes of a limit from the corresponding registered_limit. |
Unified limits consists of registered limits and limits, which are project-specific. Both types are isolated into separate database tables (keystone.registered_limit and keystone.limit). The following is the existing schema for both tables:
http://paste.openstack.org/raw/723936/
There are some duplicated attributes between these two tables that are requirements for the API (e.g. a limit cannot be created without a corresponding limit being registered first). We have the opportunity to simplify the schema of the keystone.limit table by removing limit.service_id, limit.region_id, and limit.resource_name in favor of a single column called limit.registered_limit_id that maintains a FK relationship to a record in keystone.registered_limit.
The unified limit API will use the FK relationship to populate service_id, region_id, and resource_name attributes of a limit from the corresponding registered_limit. |
|
| 2018-06-20 14:20:53 |
Lance Bragstad |
tags |
|
sql |
|
| 2018-06-20 14:21:00 |
Lance Bragstad |
tags |
sql |
limits sql |
|
| 2018-06-20 14:21:37 |
Lance Bragstad |
description |
Unified limits consists of registered limits and limits, which are project-specific. Both types are isolated into separate database tables (keystone.registered_limit and keystone.limit). The following is the existing schema for both tables:
http://paste.openstack.org/raw/723936/
There are some duplicated attributes between these two tables that are requirements for the API (e.g. a limit cannot be created without a corresponding limit being registered first). We have the opportunity to simplify the schema of the keystone.limit table by removing limit.service_id, limit.region_id, and limit.resource_name in favor of a single column called limit.registered_limit_id that maintains a FK relationship to a record in keystone.registered_limit.
The unified limit API will use the FK relationship to populate service_id, region_id, and resource_name attributes of a limit from the corresponding registered_limit. |
Unified limits consists of registered limits and limits, which are project-specific. Both types are isolated into separate database tables (keystone.registered_limit and keystone.limit). The following is the existing schema for both tables:
http://paste.openstack.org/raw/723936/
There are some duplicated attributes between these two tables that are requirements for the API (e.g. a limit cannot be created without a corresponding limit being registered first). We have the opportunity to simplify the schema of the keystone.limit table by removing limit.service_id, limit.region_id, and limit.resource_name in favor of a single column called limit.registered_limit_id that maintains a FK relationship to a record in keystone.registered_limit.
The unified limit API will use the FK relationship to populate service_id, region_id, and resource_name attributes of a limit from the corresponding registered_limit.
Possibly solutions for the migration were whiteboarded using the following etherpad:
https://etherpad.openstack.org/p/keystone-unified-limit-migration-notepad |
|
| 2018-06-22 06:08:11 |
Deepak Mourya |
bug |
|
|
added subscriber Deepak Mourya |
| 2018-06-25 07:16:08 |
wangxiyuan |
keystone: assignee |
|
wangxiyuan (wangxiyuan) |
|
| 2018-06-25 08:39:22 |
OpenStack Infra |
keystone: status |
Triaged |
In Progress |
|
| 2018-07-04 05:23:01 |
OpenStack Infra |
keystone: status |
In Progress |
Fix Released |
|
| 2019-01-28 20:47:38 |
Lance Bragstad |
keystone: milestone |
|
rocky-rc1 |
|
