yahoo-eng-team team mailing list archive

[OpenStack Infra <1777892@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/577751
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=a558eb0baba05280747ea67556e1041e86898ef3
Submitter: Zuul
Branch:    master

commit a558eb0baba05280747ea67556e1041e86898ef3
Author: wangxiyuan <wangxiyuan@xxxxxxxxxx>
Date:   Mon Jun 25 15:45:33 2018 +0800

    Add registered_limit_id column for limit
    
    This patch add a registered_limit_id column referring to
    the related registered limit for limit talbe.
    
    This change aims to reduce the duplicate data between unified
    limit tables.
    
    In Rocky, "registered_limit_id" will co-exist with "service_id",
    "region_id" and "resource_name" columns.
    
    In Stein, we'll migrate the old data to satisfy the
    "registered_limit_id" way
    
    In T release, the "service_id", "region_id" and "resource_name"
    columns will be removed at all.
    
    Closes-Bug: #1777892
    Change-Id: I9a81056b9afda924aac71f64c2158d9db53d8594


** Changed in: keystone
       Status: In Progress => Fix Released

-- 
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):
  Fix Released

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