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.
- Sage Weil (Inktank)
- Sam Just (Inktank)
- Josh Durgin
- Dan Mick
- Loic Dachary
- Christophe Courtaut firstname.lastname@example.org
- Wido den Hollander (42on)
- Xiaobing Zhou(xzhou40 (AT) hawk.iit.edu)
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.
- 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'
- 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.