Revision 43f30ee6
b/doc/design-2.0-os-interface.rst | ||
---|---|---|
20 | 20 |
interface is composed by a series of scripts which get called with certain |
21 | 21 |
parameters to perform OS-dependent operations on the cluster. The current |
22 | 22 |
scripts are: |
23 |
|
|
23 | 24 |
create |
24 | 25 |
called when a new instance is added to the cluster |
25 | 26 |
export |
... | ... | |
70 | 71 |
|
71 | 72 |
As in Ganeti 1.2, every OS which wants to be installed in Ganeti needs to |
72 | 73 |
support the following functionality, through scripts: |
74 |
|
|
73 | 75 |
create: |
74 | 76 |
used to create a new instance running that OS. This script should prepare the |
75 | 77 |
block devices, and install them so that the new OS can boot under the |
... | ... | |
95 | 97 |
|
96 | 98 |
We expect the following incompatibilities between the OS scripts for 1.2 and |
97 | 99 |
the ones for 2.0: |
100 |
|
|
98 | 101 |
- Input parameters: in 1.2 those were passed on the command line, in 2.0 we'll |
99 | 102 |
use environment variables, as there will be a lot more information and not |
100 | 103 |
all OSes may care about all of it. |
... | ... | |
114 | 117 |
|
115 | 118 |
Rather than using command line flags, as they do now, scripts will accept |
116 | 119 |
inputs from environment variables. We expect the following input values: |
120 |
|
|
117 | 121 |
INSTANCE_NAME |
118 | 122 |
Name of the instance acted on |
119 | 123 |
HYPERVISOR |
... | ... | |
150 | 154 |
|
151 | 155 |
Some scripts will need a few more information to work. These will have |
152 | 156 |
per-script variables, such as for example: |
157 |
|
|
153 | 158 |
NEW_INSTANCE_NAME |
154 | 159 |
rename: the name the instance should be renamed to. |
155 | 160 |
EXPORT_NODE |
... | ... | |
172 | 177 |
|
173 | 178 |
|
174 | 179 |
Output/Behaviour |
175 |
~~~~~~~~~~~~~~~ |
|
180 |
~~~~~~~~~~~~~~~~
|
|
176 | 181 |
|
177 | 182 |
As discussed scripts should only send user-targeted information to stdout. The |
178 | 183 |
create and import scripts are supposed to format/initialise the given block |
... | ... | |
194 | 199 |
|
195 | 200 |
|
196 | 201 |
Caveats/Notes |
197 |
------------ |
|
202 |
-------------
|
|
198 | 203 |
|
199 | 204 |
We might want to have a "default" import/export behaviour that just dumps all |
200 | 205 |
disks and restores them. This can save work as most systems will just do this, |
... | ... | |
205 | 210 |
the case we may want to go to a more complex API such as storing those |
206 | 211 |
information on the filesystem and providing the OS script with the path to a |
207 | 212 |
file where they are encoded in some format. |
208 |
|
Also available in: Unified diff