Reduce duplicate data between unified limit tables

Bug #1777892 reported by Lance Bragstad
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
Medium
wangxiyuan

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

Tags: limits sql
Changed in keystone:
importance: Undecided → Medium
status: New → Triaged
description: updated
tags: added: sql
tags: added: limits
description: updated
wangxiyuan (wangxiyuan)
Changed in keystone:
assignee: nobody → wangxiyuan (wangxiyuan)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (master)

Fix proposed to branch: master
Review: https://review.openstack.org/577751

Changed in keystone:
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master)

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 <email address hidden>
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
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/keystone 14.0.0.0rc1

This issue was fixed in the openstack/keystone 14.0.0.0rc1 release candidate.

Changed in keystone:
milestone: none → rocky-rc1
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to keystone (master)

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

commit f43954be9419e96fbe9d231aa1f5ae32cd0142eb
Author: wangxiyuan <email address hidden>
Date: Sun May 5 10:39:17 2019 +0800

    Drop limit columns

    The service_id, region_id and resource_name columns in limit table
    is useless now. These info can be got by 'registered_limit_id'
    column from registered limit table. So there is no data migration
    needed.

    Since this is a silent change for end users, there is no need for
    a release note as well.

    Related-Bug: #1777892
    Change-Id: Ibf4aa81dad7c5ebbd5599a55237cc5a658223432

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.