Public bug reported: 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 ** Affects: keystone Importance: Medium Status: Triaged ** Tags: limits sql ** Changed in: keystone Importance: Undecided => Medium ** Changed in: keystone Status: New => Triaged ** Description changed: 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). + (keystone.registered_limit and keystone.limit). The following is the + existing schema for both tables: - Currently, the schema for keystone.registered_limit is: + http://paste.openstack.org/raw/723936/ - 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. + 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. ** Tags added: sql ** Tags added: limits ** Description changed: 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 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1777892 Title: Reduce duplicate data between unified limit tables Status in OpenStack Identity (keystone): Triaged Bug 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. Possibly solutions for the migration were whiteboarded using the following etherpad: https://etherpad.openstack.org/p/keystone-unified-limit-migration- notepad To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1777892/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
