yahoo-eng-team team mailing list archive

[Lance Bragstad <lbragstad@xxxxxxxxx>]

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