1B - Ceph Management API¶
The live pad can be found here: [pad]
wCoding tasks (some done, see http://github.com/ceph/ceph branch wip-ceph-cli for an out-of-date working branch)
If you have ideas/comments/suggestions, contact us at irc.oftc.net #ceph, or email@example.com!
- Create command/param/help registry in monclient, export in JSON on request
- expression language for parameter descriptions: type, name, valid ranges/values, etc.
- make it simple to add new commands and easy to find the full list of commands supported
- Frontend CLI that requests command registry and validates user input, submits JSON command request
- do as much validation upfront as possible, as generically as possible
- write validation code such that it can be reused in REST endpoint
- format help, provide substring help
- allow for command-line completion (allow partial matching of input)
- format actual command request in unambiguous complete JSON form
- Remove existing command validation/parsing from monclient
- rely on front end to pass only valid commands as much as possible (some validation must talk to the cluster)
- refactor common tasks, like selection of output format
- Allow all formatted commands to output JSON or XML (planning ahead for REST)
- Validate all existing functionality remains unchanged with much-enhanced unit tests and existing tests
- migration path for existing 'allow command ...' cap strings
- discover/describe --admin-daemon and tell commands (currently just passthru)
- merge to master... 0.63ish?
- Add command-line completion to frontend and BASH snippets
- Create webserver for REST endpoint (after the interface is designed) using chunks of the CLI code as needed
- Allow REST endpoint to respond in JSON or XML at user's request
- Add some appropriate sort of monitoring to the REST endpoint
- ability to access daemon admin socket command set via REST mgmt endpoint
- ability to do 'tell <name> ...'
- ability to access cluster event log via cli, REST mgmt endpoint
- ceph-deploy support for deploying a management endpoint daemon
- (Possible): allow client to register interest in cluster events (cluster/OSD full, daemon status change, quorum change, administrative events/change) using an unknown mechanism (perhaps a URL that can be accessed on such events, perhaps with a parameter structure to carry information about the
Build / release tasks
- document upgrade path: upgrade cli tool first (it can talk to either old or new mons), mons second.
- merge first batch of cli stuff
- merge rest mgmt endpoint as it finishes
- Fix up manpage/webdoc for CLI; decide to document each or just defer to CLI help
- A large pile of documentation for REST API