Jump to: navigation, search

Difference between revisions of "Keystone-schema-in-cassandra"

(Trust)
(trust)
Line 250: Line 250:
 
! scope="col"| roles
 
! scope="col"| roles
 
|-
 
|-
! scope="row" colspan="7"| PK->(id)
+
! scope="row" colspan="10"| PK->(id)
 
|}
 
|}
  
 
This table has the same schema in cassandra as well.
 
This table has the same schema in cassandra as well.

Revision as of 09:09, 28 April 2015

The Cassandra tables for each of the backend in Keystone is described below.

Identity

The identity backend of Keystone holds data for users, groups and user-group membership. There are three tables in relational db for holding this data.

  • user
  • group
  • user_group_membership

user

Table in MySql

user
id domain_id name enabled password extra default_project_id
PK->(id), UK->(domain_id, name)

The equivalent of this table in Cassandra is two tables.

user
id domain_id name enabled password extra default_project_id
PK->(id)
name_index
domain_id name id
PK->(domain_id, name)
  • 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 the operations it is evident that the data for user is queried on either (domain_id), or (domain_id, name) or (user_id). Based on this information, the equivalent of this table in Cassandra would consist of two tables. All the insert, update and delete for user table goes to these two table.

group

The group table is similar to user except few fields such as password and default_project_id. This table can be designed the same way as user.

user_group_membership

Table in MySql

user_group_membership
user_id group_id
PK->(user_id, group_id), K->(group_id)

The equivalent in Cassandra is

user_group
user_id group_id
PK->(user_id, group_id)
group_user
group_id user_id
PK->(group_id, user_id)
  • 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.

Assignment

The assignment backend holds about the role assignments. It additionally has a role_backend which stores data for all the roles. There are two tables in relational db for this backend.

  • assignment
  • role

assignment

Table in MySql

type actor_id target_id role_id
PK->(type, actor_id, target_id, role_id), K->(actor_id), K->(role_id)

The equivalent in Cassandra is

assignment
type actor_id target_id role_id
PK->(type, actor_id, target_id, role_id), SI->(target_id), SI->(role_id)

There are a lot of operations in 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

Table in MySql

role
id name extra
PK->(id), UK->(name)

The equivalent in Cassandra is two tables.

role
id name extra
PK->(id)
role_name_index
name id
PK->(name)

Almost all the operations here are done with role_id information. But there is an api in v2.0 which allows you to get a role by its name. So we need the name to id mapping in second table. To preserve the uniqueness of name first a row is inserted to the role_name_index table and then if succeeds then the row is inserted to the role table.


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

project
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

domain
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

credential
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

trust
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.