Synnefo » ./kamaki

Kamaki has to be configured for a specific Synnefo deployment, with an

authentication url and user token pair. Users should also pick an alias to name

the cloud configuration. This can be any single word, e.g. "default", "mycloud"

or whatever suits kamaki users.

    $ kamaki config set cloud.<cloud alias>.url <cloud-authentication-URL>

    $ kamaki config set cloud.<cloud alias>.token myt0k3n==

If only one cloud is configured, kamaki automatically picks it as the default.

Otherwise, a default cloud should be specified:

.. code-block:: console

    $ kamaki config set default_cloud <cloud alias>

Since Synnefo version 0.14, a synnefo cloud UI offers a single authentication

URL, which should be set as the cloud URL for kamaki. All service-specific URLs

are retrieved and handled automatically by kamaki, through this URL. Users of

synnefo clouds >=0.14 are advised against using any service-specific URLs.

This section refers to running installations of kamaki version <= 0.8.X To

check the current kamaki version:

Existing kamaki users should convert their configuration files to v9. To do

that, kamaki 0.9 can inspect the configuration file and suggests a list of

config file transformations, which are performed automatically (after users'

permission). This mechanism is invoked when an API-related kamaki command is

fired. On example 2.1 we suggest using the `user authenticate` command to fire

the kamaki config file conversion mechanism.

    Config file format version >= 9.0 is required

    Configuration file: "/home/exampleuser/.kamakirc"

    ... rescue global.token => cloud.default.token

    Kamaki is ready to convert the config file to version 9.0

    In this example, the user accidentally misspelled the term `log_data`

Multiple clouds

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

frequently be called as a **cloud**.

Kamaki supports accessing multiple clouds from the same kamaki setup. Before

kamaki 0.9, this was possible only by using multiple config files. Since 0.9,

kamaki supports multiple clouds in the same configuration.

Each cloud corresponds to a Synnefo (or Open Stack) cloud deployment.

Once a user has retrieved one URL/token pair per cloud, it is time to assign a

name to each cloud and let kamaki know about them.

For example, let the user have access to two clouds with the following authentication information ::

    $ kamaki config set cloud.devel.url https://devel.example.com/astakos/identity/v2.0/

    $ kamaki config set cloud.devel.token myd3v3170k3n==

    $ kamaki config set cloud.testing.url https://testing.example.com/astakos/identity/v2.0/

    $ kamaki config set cloud.testing.token my73571ng70k3n==

To check if all settings are loaded, a user may list all clouds, as shown

    $ kamaki config getcloud 

     cloud.default.url = https://example.com/astakos.identity/v2.0/

     cloud.default.url = myd3f4u1770k3n==

     cloud.devel.url = https://devel.example.com/astakos/identity/v2.0/

     cloud.devel.token = myd3v3170k3n==

     cloud.testing.url = https://testing.example.com/astakos/identity/v2.0/

     cloud.testing.token = my73571ng70k3n==

or query kamaki for a specific cloud:

    $ kamaki config get cloud.devel

     cloud.devel.url = https://devel.example.com/astakos/identity/v2.0/

     cloud.devel.token = myd3v3170k3n==

Now kamaki can use any of these clouds, with the **- - cloud** attribute. If

the **- - cloud** option is ommited, kamaki will query the `default` cloud.

In interactive cell, the cloud is picked when invoking the shell, with

    * Add colors to command line / console output

    * Can be switched on/off in kamaki configuration file: `colors = on/off`

    * Allow unit tests to run on kamaki.clients package

Any of the above features can be installed at any time before or after kamaki

installation.

* cloud-related

    information needed to connect and use one or more clouds. There are some

    mandatory options (URL, token) and some advanced / optional (e.g.

    service-specific URL overrides or versions)

provided by the user. Kamaki-related options can also be modified.

explicitly load configuration files with the **- - config** (or **- c**) option

.. note:: For accessing multiple clouds, users do NOT need to create multiple

    configuration files. Instead, we suggest using a single configuration file

    with multiple cloud setups. More details can be found at the

    `multiple clouds guide <#multiple-clouds>`_.

    *global*.

The commands above can also be used for **clouds** handling, using the `cloud.`

prefix. The cloud handling cases are similar but with slightly different

semantics:

* kamaki config get cloud[.<cloud alias>[.option]]

    * cloud 

        list all clouds and their settings

    * cloud.<cloud alias>

        list settings of the cloud aliased as <cloud alias>. If no

        special is configured, use the term `cloud.default`

    * cloud.<cloud alias>.<option>

        configured, use `cloud.default.<option>`

* kamaki config set cloud.<cloud alias>.<option> <value>

    If the cloud alias <cloud alias> does not exist, create it. Then, create

    (or update) the option <option> of this cloud, by setting its value

* kamaki config delete cloud.<cloud alias>[.<option>]

    * cloud.<cloud alias>

    * cloud.<cloud alias>.<option>

        delete the <option> and its value from the cloud cloud aliased as

.. note:: To see if a default cloud is configured, get the default_cloud value

    .. code-block:: console

        $ kamaki config get default_cloud

    [cloud "default"]

The [cloud "default"] section is special and is used to configure the default

cloud cloud. Kamaki will not be able to run without setting the url and token

More clouds can be created  on the side of the default cloud, e.g using the

examples at the `multiple clouds guide <#multiple-clouds>`_ ::

    [cloud "devel"]

    [cloud "testing"]

In most tests, livetest will run as long as the default cloud is configured

    * livetest.testcloud = <the cloud alias this test will run against>