Ceph

*Summary*

Currently RGW follows the S3 scheme, in which users and buckets all reside in a single global tenant.

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.

All swift users within the same tenant share the same data (as with subusers under rgw user).

Buckets names don’t need to be unique across different tenants (unlike rgw).

Owners

    Yehuda (Red Hat)

*Interested Parties*

    Name (affiliation)

*Current Status*

*Detailed Description*

The suggested solution:

*Basic*

* add ‘tenant’ property to rgw users

* add ‘tenant’ property to rgw buckets

* any bucket that a user creates will reside under the user’s tenant

* buckets will not need to be unique across tenants

* user could be referred to as <tenant>:<user>

* bucket could be referred to as <tenant>#<bucket> or <tenant>/<bucket> (can’t use <tenant>:<bucket>)

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

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

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.

a tenant entity will also exist, and would have several optional configurables

default placement target (storage policy)

quota (per user in the tenant, for the entire tenant -- if implemented)

name[s] of dns entry point[s] for the tenant

*Advanced functionality*

_not necessarily part of initial solution_

ability to list users that belong to each tenant

tenant admin users that can administer their tenant

quota per tenant, statistics per tenant