Ceph Management API » History » Version 2
Jessica Mack, 06/08/2015 10:07 PM
1 | 1 | Jessica Mack | h1. Ceph Management API |
---|---|---|---|
2 | |||
3 | h3. Summary |
||
4 | |||
5 | Provide a REST API endpoint for carrying out Ceph monitoring and management tasks. |
||
6 | |||
7 | h3. Owners |
||
8 | |||
9 | * Dan Mick (Inktank) |
||
10 | |||
11 | h3. Interested Parties |
||
12 | |||
13 | * Sage Weil (Inktank) |
||
14 | * Danny Al-Gaaf |
||
15 | * Josh Durgin |
||
16 | * Joao Luis |
||
17 | * Xiaoxi Chen (Intel) |
||
18 | * Loic Dachary |
||
19 | * Wido den Hollander (42on) |
||
20 | * Hunter Nield (Acaleph) |
||
21 | * Xiaobing Zhou(xzhou40 (AT) hawk.iit.edu) |
||
22 | |||
23 | h3. Current Status |
||
24 | |||
25 | 2 | Jessica Mack | Currently the cluster is managed by manual modification of configuration and CRUSH map files, application of command operations with the @ceph@ CLI tool (and occasionally the @rados@ and @cephfs@ tools), and manual examination of log files. Each of the CLI tools interacts with the cluster as a "monclient", or client of the monitor cluster, by sending network messages to and from the monitors. |
26 | 1 | Jessica Mack | |
27 | h3. Detailed Description |
||
28 | |||
29 | Work on this project has begun. Two phases were identified: |
||
30 | |||
31 | # Recode the CLI to split out the command parsing/validation into a front-end. The first front-end will |
||
32 | ** query the underlying ceph command to discover a list of valid commands and parameters |
||
33 | ** validate user input against this command list, and return errors/help when invalid without contacting the monitors |
||
34 | ** pass the request to the monitors in regular validated form, factoring out common options |
||
35 | ** provide detailed help about each command, again discovered from the ceph tool |
||
36 | ** provide BASH completion for the command/parameters |
||
37 | ** simplify/harden monitor code by putting common parsing/marshalling in a generic front end |
||
38 | # Write a new webserver to provide similar functionality for the RESTful endpoint |
||
39 | ** leverage the mechanisms created for phase 1 |
||
40 | ** run independently from the monitors/OSDs |
||
41 | ** allow for multiple daemons for load balancing/redundancy |
||
42 | ** authenticate/validate requests |
||
43 | ** allow user discovery of APIs by querying the endpoint without a request |
||
44 | ** provide at least the set of commands supported by the CLI, but probably... |
||
45 | ** ...provide expanded summary/monitoring commands |
||
46 | |||
47 | h3. Work items |