root / doc / design-2.0-rapi-changes.rst @ c5e2d3b9
History | View | Annotate | Download (3.8 kB)
1 |
Ganeti Remote API |
---|---|
2 |
================= |
3 |
|
4 |
.. contents:: |
5 |
|
6 |
Objective |
7 |
--------- |
8 |
The Ganeti RAPI provides limited remote control over Ganeti-cluster for |
9 |
third-party applications, exposing internal Ganeti functionality via RESTful |
10 |
API. |
11 |
|
12 |
|
13 |
Goals |
14 |
~~~~~ |
15 |
|
16 |
- Provide functionality for remote cluster management. |
17 |
|
18 |
- Expose current cluster state |
19 |
|
20 |
- Must be extensible and revolvable in design |
21 |
|
22 |
- Restrict access |
23 |
|
24 |
|
25 |
Requirements |
26 |
~~~~~~~~~~~~ |
27 |
|
28 |
- Authentication |
29 |
|
30 |
- Encryption |
31 |
|
32 |
- Language independent |
33 |
|
34 |
- Reliable and easy to use |
35 |
|
36 |
|
37 |
Background |
38 |
---------- |
39 |
|
40 |
A growing amount of installations can shortly put ganeti based infrastructure |
41 |
on manageable edge. Therefore the is strong need to centralize clusters |
42 |
management, provide information for the "best placement" and cluster |
43 |
rebalancing decisions. |
44 |
|
45 |
The first Ganeti RAPI was designed and deployed with the Ganeti 1.2.5 release. |
46 |
That version provide Read-Only access to a cluster state. Fully functional |
47 |
read-write API demand significant internal changes which are in a pipeline for |
48 |
Ganeti 2.0 release. |
49 |
|
50 |
Overview |
51 |
-------- |
52 |
|
53 |
We decided to go with implementing the Ganeti RAPI in a RESTful way, which is |
54 |
aligned with key features we looking. It is simple, stateless, scalable and |
55 |
extensible paradigm of API implementation. As transport it uses HTTP over SSL, |
56 |
and we are implementing it in JSON encoding, but in a way it possible to extend |
57 |
and provide any other one. |
58 |
|
59 |
Design |
60 |
------- |
61 |
|
62 |
The Ganeti API implemented as independent daemon, running on the same node |
63 |
with the same permission level as Ganeti master daemon. Communication done |
64 |
through unix socket protocol provided by Ganeti luxi library. |
65 |
In order to keep communication asynchronous RAPI process two types of client |
66 |
requests: |
67 |
|
68 |
- queries: sever able to answer immediately |
69 |
- jobs: some time needed. |
70 |
|
71 |
In the query case requested data send back to client in http body. Typical |
72 |
examples of queries would be list of nodes, instances, cluster info, etc. |
73 |
Dealing with jobs client instead of waiting until job completes receive a job |
74 |
id, the identifier which allows to query the job progress in the job queue. |
75 |
(See job queue design doc for details) |
76 |
|
77 |
Internally, each exported object has an version identifier, which is used as a |
78 |
state stamp in the http header E-Tag field for request/response to avoid a race |
79 |
condition. |
80 |
|
81 |
|
82 |
Resource representation |
83 |
~~~~~~~~~~~~~~~~~~~~~~~ |
84 |
|
85 |
The key difference of REST approach from others API is instead having one URI |
86 |
for all our requests, REST demand separate service by resources with unique |
87 |
URI. Each of them should have limited amount of stateless and standard HTTP |
88 |
methods: GET, POST, DELETE, PUT. |
89 |
|
90 |
For example in Ganeti case we can have a set of URI: |
91 |
- /{clustername}/instances |
92 |
- /{clustername}/instances/{instancename} |
93 |
- /{clustername}/instances/{instancename}/tag |
94 |
- /{clustername}/tag |
95 |
|
96 |
A GET request to /{clustername}/instances will return list of instances, a POST |
97 |
to /{clustername}/instances should create new instance, a DELETE |
98 |
/{clustername}/instances/{instancename} should delete instance, a GET |
99 |
/{clustername}/tag get cluster tag |
100 |
|
101 |
Each resource URI has a version prefix. The complete list of resources id TBD. |
102 |
|
103 |
Internal encoding might be JSON, XML, or any other. The JSON encoding fits |
104 |
nicely in Ganeti RAPI needs. Specific representation client can request with |
105 |
Accept field in the HTTP header. |
106 |
|
107 |
The REST uses standard HTTP as application protocol (not just as a transport) |
108 |
for resources access. Set of possible result codes is a subset of standard HTTP |
109 |
results. The stateless provide additional reliability and transparency to |
110 |
operations. |
111 |
|
112 |
|
113 |
Security |
114 |
-------- |
115 |
|
116 |
With the write functionality security becomes much bigger an issue. The Ganeti |
117 |
RAPI uses basic HTTP authentication on top of SSL connection to grant access to |
118 |
an exported resource. The password stores locally in Apache-style .htpasswd |
119 |
file. Only one level of privileges is supported. |