Ceph

h1. Rados namespaces

h3. Summary

RADOS currently uses pools both for data distribution (pools are shared into PGs, which map to OSDs) and as the granularity for security (capabilities can restrict access by pool).  Overloading pools for both purposes makes it hard to do multi-tenancy because it not a good idea to have a very large number of pools.

A namespace would be a division of a pool into separate logical namespaces.  Instead of (pool, object) to identify an object, it would be (pool, namespace, object) where the default namespace is the empty string. 

h3. Owners

* Sage Weil (Inktank)

* Sam Just (Inktank)

h3. Interested Parties

* Josh Durgin

* Dan Mick

* Loic Dachary

* Christophe Courtaut christophe.courtaut@gmail.com

* Wido den Hollander (42on)

* Xiaobing Zhou(xzhou40 (AT) hawk.iit.edu)

h3. Current Status

There is some underlying plumbing in the OSD to make this possible: the FileStore already has a (currently unused) namespace field that should let us avoid an expensive disk format update/conversion to add namespace support.

h3. Detailed Description

- a namespace will be a logical separation of a pool

- the librados API will need new methods to specify the namespace for most operations.  any legacy operation will implicitly be namespace=''.

- the osd cap syntax/grammar will be extended to allow caps like 'allow pool foo namespace bar rwx'

Open questions:

- namespace enumeration: will it be supported?  the simplest approach is to not support it explicitly and instead just add the namespace field to the object enumeration path (which is O(n)).

- namespace stats: will it be supported?  probably not, at least initially.  the stats (object count, byte count) will remain per-pool.

h3. Work items