Synnefo » ./kamaki

What's more, kamaki offers a clients API that allows the developement of external applications for synnefo. The clients API is listed in the `Clients lib <clients.html>`_ section. The recomended method of utilizing this API is explained in the present.

Kamaki interfaces rely on a list of configuration options. In the initial state, kamaki is configured to communicate with the Okenos IaaS. A detailed guide for setting up kamaki can be found in the `Setup <setup.html>`_ section.

To use the storage service, a user should also provide the corresponding username:

Command line interfaces

-----------------------

Kamaki users can access synnefo services through either the interactive shell or the one-command behaviors. In practice, both systems relly on the same command set implementations and API clients, with identical responses and error messages. Still, there are some differenses.

^^^^^^^^^^^^^^^^^^^^

* session history with "up"/"down" keys

* shorter commants with command namespace switching

""""""""""""

""""""""""""""""""

^^^^^^^^

The "server" command group is also refered in the following example.

Client commands can feature an arbitarry number of terms:

Although there are no multi-termed client commands until version 0.6.1 , the feature is supported and might be used in feature extentions.

The commands supported in version 0.6.1 are described bellow, grouped by service. The examples showcase a sample set of group commands. The kamaki interactive shell has been chosen as the execution enviroment:

""""""""""""""""""""""""""

"""""""""""""""""""""""""

""""""""""""""""""""""""""""""""""

"""""""""""""""""""""""""

""""""""""""""""""""""""""

"""""""""""""""""""""""

    * Download pasted file to local filesystem *

^^^^^^^^^^^^^^^^^^^^^

""""""""""

    Example 4.1.2: Cyclades help contains all first-level commands of cyclades command group

    Example 4.1.3: Help for command "server list" with syntax, description and avaiable user options

"""""""""""""

"""""

In case of errors, kamaki in debug mode shows usefull debug information, like the stack trace, instead of a user-friendly error message. Kamaki also suppresses various warning messages that are also allowed in debug mode.

Most kamaki commands are translated into http requests. Kamaki clients API translated the semantics to REST and handles the response. Users who need to have access to these commands can use the verbose mode that presentes the HTTP Request details as well as the full server response.

""""""""""""""""""""

The -o argument can be used to overide temporarily various (set or unset) options. In one command, all -o options are forgoten just after the command had been completed, and the previous settings are restored (the configuration file is not modified).

The astakos-authenticate command in example 4.4.1 run against an explicitly provided token, which temporarily overode the token provided in the configuration file.

^^^^^^^^^^^^^^^^^

""""""""""""""""

The kamaki interactive shell implements the notion of command contexts. Each command group is also a context where the users can **enter** by typing the group name. If the context switch is succesful, the kamaki shell prompt changes to present the new context ("store" in example 5.1.1).

    Example 5.1.1: Enter store commands context/group

Type **exit** or **ctrl-D** to exit a context and return to the context of origin. If already at the top context (kamaki), an exit is equivalent to exiting the programm.

Help

""""

In context-level, there is a distinction between kamaki-commands and interactive shell commands. The former are available in one-command mode and are releated to the cloud client setup and use, while the later are context-shell functions.

    <arguments and possible extentions>

""""""""""""""""""""""""""""

When working in a context, it is often usefull to access other contexts or top-level commands. Kamaki offers access to top-level commands by using the / prefix, as shown bellow::

It is often the case that a user who works in the context command, needs to create a new VM, but doesn't know the flavor or image id of preference. Therefore, it is nessecary to list all available flavors (flavor-list) or images (image-list. Both commands belong to different contexts.

An other example (5.3.2) showcases how to aquire and modify configuration settings from a different context. In this scenario, the user token expires at server side while the user is working. When that happens, the system responds with an *(401) UNAUTHORIZED* message. The user can aquires a new token (with a browser) which has to be set to kamaki.

Config

""""""

The configuration mechanism of kamaki is detailed at the `setup section <setup.html>`_ and it is common for both interaction modes. In specific, the configuration mechanism is implemented as a command group, namely *config*. Using the config commands is as straighforward as any other kamaki commands.

It is often usefull to set, delete or update a value. This can be managed either inside the config context or from any commant context by using the / detour.

In example 5.4.1 the user is going to work with only one storage container. The store commands use the container:path syntax, but if the user could set a container as a defaul, the container name could be ommited in most cases. This is possible by setting a store.container setting.

.. warning:: In some cases, the config setting updates are not immidiately effective. If that is the case, they will be after the next command run, whatever that command is.

History

"""""""

Session history is only available in interactive shell mode. Users can iterrate through past commands in the same session by with the *up*and *down* keys. Session history is not stored, although syntactically correct commands are recorded through the permanent history mechanism

""""""""""""""

""""""""""""""""""""

Creating applications with the Clients API

------------------------------------------