Skip to content
UENISHI Kota edited this page Feb 17, 2016 · 4 revisions

This page tries to describe how buckets and users are represented and stored, in Riak CS.

  • Data structure, aka schema-ish
  • How they are updated, read and managed consistent
  • Bucket metadata
  • User metadata
  • ACLs and Policies

Users

Users are represented as a record in the big one header. It is t2b'd and stored in moss.users bucket with a key represented by access key. It contains user name, display name, access key, secret key, canonical ID, the list of all buckets.

Note that there are several indexes on this, with Email, Canonical ID to guarantee uniqueness when creating a user.

Sibling resolution of user record is implemented in riak_cs_user:from_riakc_obj/2 (not exported).

Buckets

Buckets are represented as a record in user record. It also has another entry in moss.buckets bucket with a key represented by bucket name. Note that bucket ACLs and bucket policies are stored in metadata of this entry, with metadata key X-Moss-Acl and X-Rcs-Plicy respectively.

Bucket name must be unique, RFC1355 compliant.

CRUD on users and buckets

Summary: all update requests are through Stanchion. But user update is a little bit trickey - only bucket update is serialized by Stanchion.

Critical sections of all APIs on updating users and buckets are via velvet (merged in main CS repo since 2.1).

Creating a bucket

  1. CS makes sure no bucket record entry with same name exists in moss.buckets of Riak
  2. CS performs PUT to Stanchion, with the name of the creator
  3. Stanchion makes sure no manifests remains in the manifest bucket, and no bucket record entry with the same name exists
  4. Stanchion performs put bucket object to moss.buckets
  5. CS performs update on user record (at moss.users)

Updates and deletes have mostly the same flow.

Creating a user

  1. CS generates a new user's key and secret from UUID v4 binary
  2. CS checks a new user's email is not already used via 2i query
  3. Stanchion makes that the email of the user is available
  4. Stanchion puts a user record to moss.users

For development purpose, riak_cs_user:create_user/4 via attached console is the fastest way to create a new user.

Updating a user, including disabling

  1. CS checks the user exists
  2. Stanchion makes sure that the new email address is available if changed
  3. Stanchion puts a user record to moss.users

ACLs and Policies

Bucket object (r_o) is updated via Stanchion. riak_cs_wm_utils:bucket_access_authorize_helper/4, riak_cs_wm_utils:object_access_authorize_helper/4 and riak_cs_wm_utils:object_access_authorize_helper/5 would be a good introduction to learn application of ACL and Policy.

Access Control Lists is tested first and Bucket Policies (example) are tested next. After them quota modules are evaluated. See quota code document.