Revision f6822a26 docs/examplesdir/imageregister.rst
| b/docs/examplesdir/imageregister.rst | ||
|---|---|---|
| 14 | 14 |
|
| 15 | 15 |
pithos:debian_base3.diskdump |
| 16 | 16 |
|
| 17 |
The crussial element in an image location is the container (e.g. `pithos`) and |
|
| 18 |
the image object path (e.g. `debian_base3.diskdump`). |
|
| 17 |
.. note:: The image API requires the image location in the form |
|
| 18 |
|
|
| 19 |
*pithos://<user uuid>/<container>/<object path>* |
|
| 20 |
|
|
| 21 |
The translation between |
|
| 22 |
the two formats is handled internally by kamaki. The latest format is still |
|
| 23 |
acceptable by kamaki due to backward compatibility but it is going to be deprecated from kamaki 0.12 and on. |
|
| 19 | 24 |
|
| 20 | 25 |
|
| 21 | 26 |
Register an image |
| ... | ... | |
| 64 | 69 |
the image file and then register it as an image, and is equivalent to manually |
| 65 | 70 |
calling **/file upload** and **/image register**. |
| 66 | 71 |
|
| 67 |
In other words, the example that follows is equivalent to calling the two |
|
| 68 |
operations above. |
|
| 72 |
In other words, the preceding and following command sequences are equivalent. |
|
| 69 | 73 |
|
| 70 | 74 |
.. code-block:: console |
| 71 | 75 |
|
| ... | ... | |
| 168 | 172 |
OS: Linux |
| 169 | 173 |
user: someuser |
| 170 | 174 |
|
| 171 |
These properties can be added freely by the user, and they have no significance |
|
| 172 |
for the image server, but they could be used to help using the image more |
|
| 173 |
efficiently. |
|
| 175 |
These properties can be added freely by the user, and they are not required by |
|
| 176 |
the image server, but they can be used by many applications. |
|
| 174 | 177 |
|
| 175 |
Attempt to register with properties
|
|
| 178 |
Attempt to register an image with custom properties
|
|
| 176 | 179 |
|
| 177 | 180 |
.. code-block:: console |
| 178 | 181 |
|
| ... | ... | |
| 180 | 183 |
Metadata file pithos:debian_base3.diskdump.meta already exists |
| 181 | 184 |
[kamaki]: |
| 182 | 185 |
|
| 183 |
It's true that the metafile is already there, but we can override it (**-f**) |
|
| 186 |
It's true that a metafile with this name is already there, but we can override |
|
| 187 |
it (**-f**) |
|
| 184 | 188 |
|
| 185 | 189 |
.. code-block:: console |
| 186 | 190 |
|
| ... | ... | |
| 199 | 203 |
Done |
| 200 | 204 |
[kamaki]: |
| 201 | 205 |
|
| 202 |
The metadata file can be edited. Let's edit the file, by adding properties::
|
|
| 206 |
The metadata file can be edited. Let's edit the file to add these properties::
|
|
| 203 | 207 |
|
| 204 | 208 |
OS: Linux |
| 205 | 209 |
user: root |
| ... | ... | |
| 272 | 276 |
[kamaki]: image meta set 7h1rd-1m4g3-1d --name='Changed Name' |
| 273 | 277 |
[kamaki]: |
| 274 | 278 |
|
| 275 |
If we, now, get the image metadata, we will see that the name is changed:
|
|
| 279 |
A look at the image metadata reveals that the name is changed:
|
|
| 276 | 280 |
|
| 277 | 281 |
.. code-block:: console |
| 278 | 282 |
|
| ... | ... | |
| 305 | 309 |
[kamaki]: image meta set 7h1rd-1m4g3-1d --unpublish |
| 306 | 310 |
[kamaki]: |
| 307 | 311 |
|
| 308 |
The first call published the image (set is-public to True) and also restored
|
|
| 309 |
the name to "Debian Base Gama". The second one unpublished the image (set
|
|
| 312 |
The first call publishes the image (set is-public to True) and also restores
|
|
| 313 |
the name to "Debian Base Gama". The second one unpublishes the image (set
|
|
| 310 | 314 |
is-public to False). |
| 311 | 315 |
|
| 312 |
To delete metadata, use the image meta delete method: |
|
| 316 |
To delete metadata, use the image meta delete method. For example, the |
|
| 317 |
following will set the value of *status* to an empty string: |
|
| 313 | 318 |
|
| 314 | 319 |
.. code-block:: console |
| 315 | 320 |
|
| 316 | 321 |
[kamaki]: image meta delete 7h1rd-1m4g3-1d status |
| 317 | 322 |
[kamaki]: |
| 318 | 323 |
|
| 319 |
will empty the value of "status". |
|
| 320 | 324 |
|
| 321 | 325 |
These operations can be used for properties with the same semantics: |
| 322 | 326 |
|
| ... | ... | |
| 370 | 374 |
produced automatically at the server side, was the same. This is due to the |
| 371 | 375 |
fact that image ids are 1 to 1 related to image objects uploaded to Pithos+ |
| 372 | 376 |
|
| 373 |
**An explicit name overrides the metafile** |
|
| 377 |
**An explicit image name overrides the metafile**
|
|
| 374 | 378 |
|
| 375 | 379 |
Each image needs a name and this is given as the first argument of the |
| 376 | 380 |
`register` command. This name overrides the name in the metafile. |
| 377 | 381 |
|
| 378 |
**Reregistration is not update, but an override** |
|
| 382 |
**Reregistration is not an update, but an override**
|
|
| 379 | 383 |
|
| 380 | 384 |
The property `user: root` won over `user: someuser`, because it was set last. |
| 381 | 385 |
Actually, all properties were replaced by the new ones, when the image was |
| ... | ... | |
| 560 | 564 |
images (all images will be named after their relative paths). |
| 561 | 565 |
|
| 562 | 566 |
Also, let the registered images be public (accessible to all users for creating |
| 563 |
VMs) by adding the **--public** flag argument when calling `image register`.
|
|
| 567 |
VMs) by adding the **- - public** flag argument when calling `image register`.
|
|
| 564 | 568 |
|
| 565 | 569 |
.. code-block:: console |
| 566 | 570 |
|
Also available in: Unified diff