Keystone-schema-in-cassandra

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.

The operations pertaining to this table rely on being able to access data given one of the following sets of columns: (domain_id), (domain_id, name), (id). The equivalent operations in Cassandra are supported by the following two tables.

The group table
The group table in MySQL is similar to the user table, and is as follows.

The operations pertaining to this table rely on being able to access data given one of the following sets of columns: (domain_id), (domain_id, name), (id). 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.

The user_group_membership Table
The user_group_membership table used in MySQL is as follows.

The operations pertaining to this table rely on accessing data given one of the following sets of columns: (user_id), (user_id, group_id), (group_id), or (group_id, user_id). 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 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.

The operations pertaining to this table are based on one of the following sets of columns: (type, actor_id, target_id, role_id), (type, actor_id, target_id), (actor_id), (target_id), or (role_id). This table looks the same in Cassandra. Additionally there are two secondary index on columns target_id and role_id. These are intended to be used when a role_id or target_id is deleted from Keystone.

Note: Since the Hierarchical Multi-Tenancy feature is not yet included in this schema design, the inherited column has been omitted from the Cassandra schema.

The role Table
The role table in MySQL is as follows. 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.

Resource
The resource backend holds data about projects and domains. There are two tables in this backend.
 * project
 * domain

The project Table
The project table in MySQL is as follows. The operations pertaining to this table are based on one of the following sets of columns: (id), (domain_id), or (domain_id, name). Currently, this schema does not account for Hierarchical Multi Tenancy, which will be done 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.

The domain Table
The domain table in MySQL is as follows.

The operations on this table are based on the id column. These operations are supported by following tables in Cassandra.

Credential
The Credential backend holds data related to EC2 credentials. It has one table.

The credential Table
The credential table in MySQL is as follows.

The operations pertaining to this table are based on one of the following columns: (id), (user_id), or (project_id). These operations are supported by the following Cassandra table. Additionally as an optimization later, secondary indices can be created on columns user_id and project_id.

Trust
The Trust backend stores data related to trust delegation functionality offered to users.

The trust and ""trust_role"" Tables
There are two tables pertaining to this backend, trust and trust_role. They are as follows.

These two tables can be combined into a single table in Cassandra. The roles are stored as a set. Cassandra provides support for richer data types for its columns.