RGW Multitenancy » History » Version 1
Jessica Mack, 08/26/2015 02:19 AM
| 1 | 1 | Jessica Mack | h1. RGW Multitenancy |
|---|---|---|---|
| 2 | |||
| 3 | h3. Summary |
||
| 4 | |||
| 5 | Currently RGW follows the S3 scheme, in which users and buckets all reside in a single global tenant. |
||
| 6 | Swift, on the other hand has a distinct tenant entity. Note that the swift tenant is closer to the rgw user in functionality, whereas the swift users are closer to the rgw subusers. |
||
| 7 | All swift users within the same tenant share the same data (as with subusers under rgw user). |
||
| 8 | Buckets names don’t need to be unique across different tenants (unlike rgw). |
||
| 9 | |||
| 10 | h3. Owners |
||
| 11 | |||
| 12 | * Yehuda (Red Hat) |
||
| 13 | |||
| 14 | h3. Interested Parties |
||
| 15 | |||
| 16 | * Name (affiliation) |
||
| 17 | |||
| 18 | h3. Current Status |
||
| 19 | |||
| 20 | h3. Detailed Description |
||
| 21 | |||
| 22 | The suggested solution: |
||
| 23 | Basic |
||
| 24 | add ‘tenant’ property to rgw users |
||
| 25 | add ‘tenant’ property to rgw buckets |
||
| 26 | any bucket that a user creates will reside under the user’s tenant |
||
| 27 | buckets will not need to be unique across tenants |
||
| 28 | user could be referred to as <tenant>:<user> |
||
| 29 | bucket could be referred to as <tenant>#<bucket> or <tenant>/<bucket> (can’t use <tenant>:<bucket>) |
||
| 30 | for backward compatibility, the global tenant also exists, in which the tenant name is empty. Accessing a bucket through the virtual dns bucket naming scheme (e.g., bucket.dreamhost.com), will got to the bucket in the global region. A configurable will make it possible to change this scheme to be able to specify a tenant, e.g. <bucket>.<tenant>.<domain>. |
||
| 31 | when a user refers to a user or a bucket, if the tenant is not specified its own tenant will be used; when a user specifies permissions on object / bucket, each acl that specifies another user will refer to its own tenant by default. E.g., |
||
| 32 | User sage under the redhat tenant (redhat:sage) gives greg permissions, sage could either specify redhat:greg <- READ_ONLY, or just greg <- READ_ONLY, as greg and sage are on the same tenant. |
||
| 33 | a tenant entity will also exist, and would have several optional configurables |
||
| 34 | default placement target (storage policy) |
||
| 35 | quota (per user in the tenant, for the entire tenant -- if implemented) |
||
| 36 | name[s] of dns entry point[s] for the tenant |
||
| 37 | Advanced functionality, not necessarily part of initial solution |
||
| 38 | ability to list users that belong to each tenant |
||
| 39 | tenant admin users that can administer their tenant |
||
| 40 | quota per tenant, statistics per tenant |
||
| 41 | |||
| 42 | h3. Work items |
||
| 43 | |||
| 44 | h4. Coding tasks |
||
| 45 | |||
| 46 | # Task 1 |
||
| 47 | # Task 2 |
||
| 48 | # Task 3 |
||
| 49 | |||
| 50 | h4. Build / release tasks |
||
| 51 | |||
| 52 | # Task 1 |
||
| 53 | # Task 2 |
||
| 54 | # Task 3 |
||
| 55 | |||
| 56 | h4. Documentation tasks |
||
| 57 | |||
| 58 | # Task 1 |
||
| 59 | # Task 2 |
||
| 60 | # Task 3 |
||
| 61 | |||
| 62 | h4. Deprecation tasks |
||
| 63 | |||
| 64 | # Task 1 |
||
| 65 | # Task 2 |
||
| 66 | # Task 3 |