2G - RADOS namespaces CRUSH language extension CRUSH library¶

Live Pad¶

The live pads can be found here: [pad 1] [pad 2] [pad 3]

Summit Snapshot¶

RADOS Namespaces¶

Coding tasks

1. protocol update for MOSDOp, MOSDOpReply to add namespace fields
2. librados API changes: new versions of a handful of calls to add the new fields
   1. [aio_]operate (add C interface)
3. os/FileStore changes
   1. almost nothing; hobject_t has a ns field.
   2. extend object file naming scheme and omap key naming scheme as needed (this may already be handled with the last hobject_t rev we did last year) [or maybe they already have them]
4. extend OSDCap grammar and associated tests
   1. allow pool <foo> namespace <bar>
5. OSD changes: add ns argument every that object is used
   1. anywhere there is an sobject_t... hopefully none or very few
6. manage compatibility: make OSD error out gracefully if not all replicas support namespaces, prevent downgrade, etc. This may require a global osdmap flag indicating that namespaces are supported.
   1. once all osds in the OSDMap have the feature, we set the flag in the OSDMap
   2. MOSDBoot needs to communicate features
7. extend librados list_objects() to have a ns field (along with object name and key)
8. Update RBD to allow images to live in namespaces.
   1. inventing a convenience syntax? pool/namespace/image or pool/image ?
   2. disallow / and @ and : in image names
9. Add namespace argument to rados cli tool
10. make rados bench write into a namespace!
11. add rados tool command to remove a namespace

Testing tasks

1. extend librados API tests
2. extend existing filestore and osd stress tests to stress the namespace code
   1. make radosmodel test list_objects() [at a snapshot!!]
3. extend osd cap tests

Documentation tasks

1. Document OSDCap grammar and semantics
2. Document namespace purpose, uses, and limitations
3. Document how namespaces can be leveraged by OpenStack RBD users

Things we do support:

1. unbounded # of namespaces
2. security limits by namespace

Things we don't support:

1. efficient listing of namespace
2. efficient listing of namespace contexts
3. per-namespace stats

CRUSH Language Extension¶

Coding tasks

1. extend rule parser
2. extend mapping function to implement new rule language
3. port to kernel implementation
4. define apppriate compatibility bits and integrate into existing Ceph compat checks

Documentation tasks

1. document new rule language

Possibilities:

1. a stack to supplement the working vector
2. chooseleaf would take a min # of unique items as well as total count of item
   1. needs some way to intelligently separate items beneath that point when there are dups
3. sum over map of (type -> weight) instead of just weight
4. block bucket summation

Expand crush tester/simulator

Comments:

• You might want to look into the route-map user interface of Cisco routers. I thought it handles significantly complex policies the same level as we want in this case.

CRUSH Library¶

Coding tasks

1. clean up existing API for consistency, argument types, etc.
2. define new API (C and/or C++)
3. refactor CRUSH code
4. adjust Ceph code to utilize new API
5. build (at least a basic) unit test suite for the new API

Build / release tasks

1. adjust ceph build
2. package libcrush separately (deb, rpm)

Documentation tasks

1. document new crush API