Difference between revisions of "Keystone-schema-in-cassandra"
m (→The 'assignment' Table) |
m (→role) |
||
Line 179: | Line 179: | ||
There are a number of operations on this backend. All the operations are not written here for brevity. This table looks the same in Cassandra. There are two secondary index on columns target_id and role_id. These would come handy when a role_id or target_id is deleted from Keystone. | There are a number of operations on this backend. All the operations are not written here for brevity. This table looks the same in Cassandra. There are two secondary index on columns target_id and role_id. These would come handy when a role_id or target_id is deleted from Keystone. | ||
− | ====role==== | + | ====The 'role' Table==== |
− | + | The role table in MySQL is as follows. | |
{| class="wikitable" | {| class="wikitable" | ||
|+ role | |+ role | ||
Line 188: | Line 188: | ||
! scope="col"| extra | ! scope="col"| extra | ||
|- | |- | ||
− | ! scope="row" colspan="3"| | + | ! scope="row" colspan="3"| Primary Key: (id), Unique Key: (name) |
|} | |} | ||
− | + | Most of the operations on this table are done based on role_id. There is an api in v2.0 which allows the client to get a role by its name. So we need the name to id mapping in second table. To preserve the uniqueness of the name, a row is first inserted to the role_name_index table. If that succeeds then the row is inserted to the role table. | |
The equivalent in Cassandra is two tables. | The equivalent in Cassandra is two tables. | ||
{| class="wikitable" | {| class="wikitable" | ||
Line 209: | Line 209: | ||
! scope="row" colspan="2"| Primary Key: (name) | ! scope="row" colspan="2"| Primary Key: (name) | ||
|} | |} | ||
− | |||
− | |||
===Resource=== | ===Resource=== |
Revision as of 11:50, 29 April 2015
Contents
Introduction
The purpose of this wiki article is to describe the Cassandra tables for each of the backends of Keystone. A discussion of the general concepts related to schema design in Cassandra has been covered separately.
Identity
The identity backend of Keystone holds data for users, groups and user-group membership. There are three tables in the MySQL DB for this purpose.
- user
- group
- user_group_membership
The 'user' Table
The user table in MySQL is as follows.
id | domain_id | name | enabled | password | extra | default_project_id |
---|---|---|---|---|---|---|
Primary Key: (id), Unique Key: (domain_id, name) |
The operations on this table are as follows.
- create_user(user_id, user)
- delete_user(user_id)
- update_user(domain_id, user_id, user)
- get_user(user_id)
- get_user_by_name(domain_id, name)
- list_users(domain_id)
From these it is evident that the data for user is queried on either (domain_id), or (domain_id, name), or (user_id). The equivalent operations in Cassandra, subject to eventual consistency, are supported by the following two tables.
id | domain_id | name | enabled | password | extra | default_project_id |
---|---|---|---|---|---|---|
Primary Key: (id) |
domain_id | name | id |
---|---|---|
Primary Key: (domain_id, name) |
The 'group' table
The group table in MySQL is similar to the user table, and is as follows.
id | domain_id | name | extra | description |
---|---|---|---|---|
Primary Key: (id), Unique Key: (domain_id, name) |
Keeping the equivalent data in Cassandra is done similarly to what was done with the user table, i.e., with two Cassandra tables as follows.
id | domain_id | name | extra | description |
---|---|---|---|---|
Primary Key: (id) |
domain_id | name | id |
---|---|---|
Primary Key: (domain_id, name) |
The 'user_group_membership' Table
The user_group_membership table used in MySQL is as follows.
user_id | group_id |
---|---|
Primary Key: (user_id, group_id), Key: (group_id) |
The operations performed on this table are as follows.
- add_user_to_group(user_id, group_id)
- check_user_in_group(user_id, group_id)
- remove_user_from_group(user_id, group_id)
- list_users_in_group(group_id)
- list_groups_for_user(group_id)
There are two types of operations here. One is based on user_id and another is based on group_id. So there are two tables in Cassandra to store user_group_membership. All the insert, update and delete go to both the tables in Cassandra.
user_id | group_id |
---|---|
Primary Key: (user_id, group_id); clustering column: group_id |
group_id | user_id |
---|---|
Primary Key: (group_id, user_id); clustering column: user_id |
Assignment
The assignment backend holds data about the role assignments. It additionally has a role_backend which stores data for all the roles. There are two tables in the MySQL DB.
- assignment
- role
The 'assignment' Table
The assignment table in MySQL is as follows.
type | actor_id | target_id | role_id |
---|---|---|---|
Primary Key: (type, actor_id, target_id, role_id), Key: (actor_id), Key: (role_id) |
The equivalent in Cassandra is
type | actor_id | target_id | role_id |
---|---|---|---|
Primary Key: (type, actor_id, target_id, role_id), Secondary Indices: (target_id) and (role_id) |
There are a number of operations on this backend. All the operations are not written here for brevity. This table looks the same in Cassandra. There are two secondary index on columns target_id and role_id. These would come handy when a role_id or target_id is deleted from Keystone.
The 'role' Table
The role table in MySQL is as follows.
id | name | extra |
---|---|---|
Primary Key: (id), Unique Key: (name) |
Most of the operations on this table are done based on role_id. There is an api in v2.0 which allows the client to get a role by its name. So we need the name to id mapping in second table. To preserve the uniqueness of the name, a row is first inserted to the role_name_index table. If that succeeds then the row is inserted to the role table. The equivalent in Cassandra is two tables.
id | name | extra |
---|---|---|
Primary Key: (id) |
name | id |
---|---|
Primary Key: (name) |
Resource
The resource backend holds data about projects and domains. There are two tables in this backend.
- project
- domain
project
The project table in MySql
id | domain_id | name | enabled | description | extra | parent_id |
---|---|---|---|---|---|---|
PK->(id), UK->(domain_id, name), K->(parent_id) |
This table is going under heavy changes since we started designing Cassandra backend. So we have left out HMT as of now from our design. It won't be too difficult to add it later. If we leave out the parent_id part in this table, then this table looks exactly similar to user table and also is modeled exactly the same.
domain
Table in MySql
id | name | extra |
---|---|---|
PK->(id), UK->(name) |
Again this table looks the same as role table and is modeled similarly to it.
Credential
The credential table holds data about the user credentials, for eg. EC2 credentials.
credential
Table in MySql
id | user_id | project_id | blob | type | extra | |
---|---|---|---|---|---|---|
PK->(id) |
The table has the same schema in cassandra as well.
Trust
The trust table stores data about trust(https://wiki.openstack.org/wiki/Keystone/Trusts) offered to a user.
trust
Table in MySql
id | trustor_user_id | trustee_user_id | project_id | impersonation | deleted_at | expires_at | remaining_uses | extra | roles |
---|---|---|---|---|---|---|---|---|---|
PK->(id) |
This table has the same schema in cassandra as well.