Revision ef79eb82 doc/design-2.0-os-interface.rst
b/doc/design-2.0-os-interface.rst | ||
---|---|---|
101 | 101 |
- Input parameters: in 1.2 those were passed on the command line, in 2.0 we'll |
102 | 102 |
use environment variables, as there will be a lot more information and not |
103 | 103 |
all OSes may care about all of it. |
104 |
- Input/Output: in 1.2 import scripts accepted the instance contents from |
|
105 |
standard input, and export scripts exported it to standard output. This can't |
|
106 |
be done in 2.0 as we can have more than one disk and so we wouldn't have a |
|
107 |
way to distinguish them. A target/source node and directory will be instead |
|
108 |
passed, for the import script to do the correct job. All scripts will get |
|
109 |
nothing in input and are supposed to output only user-relevant messages. |
|
104 |
- Number of calls: export scripts will be called once for each device the |
|
105 |
instance has, and import scripts once for every exported disk. Imported |
|
106 |
instances will be forced to have a number of disks greater or equal to the |
|
107 |
one of the export. |
|
110 | 108 |
- Some scripts are not compulsory: if such a script is missing the relevant |
111 | 109 |
operations will be forbidden for instances of that os. This makes it easier |
112 | 110 |
to distinguish between unsupported operations and no-op ones (if any). |
... | ... | |
162 | 160 |
|
163 | 161 |
OLD_INSTANCE_NAME |
164 | 162 |
rename: the name the instance should be renamed from. |
165 |
EXPORT_NODE |
|
166 |
import/export: node where the export should be saved to or sourced from. |
|
167 |
EXPORT_PATH |
|
168 |
import/export: the place where exports are/should be saved to. |
|
169 |
EXPORT_COMPRESSION |
|
170 |
import/export: the type of compression for the exports. |
|
171 |
|
|
172 |
(Rationale for the EXPORT_NODE, EXPORT_PATH decision: giving always a local |
|
173 |
path would require either copying exports around, which takes a lot of |
|
174 |
time/resources or depending on some type of remote filesystem to mount |
|
175 |
resources on different nodes, which would add even more complexity to the |
|
176 |
ganeti code, and can be added later, if really needed.) |
|
163 |
EXPORT_DEVICE |
|
164 |
export: device to be exported, a snapshot of the actual device. The data must be exported to stdout. |
|
165 |
EXPORT_INDEX |
|
166 |
export: sequential number of the instance device targeted. |
|
167 |
IMPORT_DEVICE |
|
168 |
import: device to send the data to, part of the new instance. The data must be imported from stdin. |
|
169 |
IMPORT_INDEX |
|
170 |
import: sequential number of the instance device targeted. |
|
177 | 171 |
|
178 | 172 |
(Rationale for INSTANCE_NAME as an environment variable: the instance name is |
179 | 173 |
always needed and we could pass it on the command line. On the other hand, |
... | ... | |
184 | 178 |
Output/Behaviour |
185 | 179 |
~~~~~~~~~~~~~~~~ |
186 | 180 |
|
187 |
As discussed scripts should only send user-targeted information to stdout. The
|
|
181 |
As discussed scripts should only send user-targeted information to stderr. The
|
|
188 | 182 |
create and import scripts are supposed to format/initialise the given block |
189 | 183 |
devices and install the correct instance data. The export script is supposed to |
190 |
export instance data to a target node in a format understandable by the the |
|
191 |
import script. The rename script should only modify the instance's knowledge of |
|
192 |
what its name is. |
|
184 |
export instance data to stdout in a format understandable by the the import |
|
185 |
script. The data will be compressed by ganeti, so no compression should be |
|
186 |
done. The rename script should only modify the instance's knowledge of what |
|
187 |
its name is. |
|
193 | 188 |
|
194 | 189 |
Other declarative style features |
195 | 190 |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
Also available in: Unified diff