@@ -7,7 +7,7 @@ Since version 0.6 it is safe to use threaded connections.
The Connection package uses httplib, standard python threads and a connection pooling mechanism.
.. note:: in versions 0.6.0 to 0.6.1 the GRNET Synnefo *snf-common* package is used for its connection pooling module. Since version 0.6.2 the underlying pooling mechanism is packed in a new GRNET package called *objpool*, which is now used instead of snf-common.
.. note:: Since version 0.6.2 the underlying pooling mechanism is packed in a new GRNET package called *objpool*.
@@ -22,20 +22,22 @@ Add the following to apt sources list
As root, append one of the following to */etc/apt/sources.list*:
* Debian Stable (kamaki 0.6.2)::
* Debian Stable::
deb http://apt.dev.grnet.gr/ squeeze main
deb http://apt2.dev.grnet.gr stable/
* Ubuntu (kamaki 0.6.2)::
* Ubuntu::
deb http://apt.dev.grnet.gr/ precise main
deb http://ppa.launchpad.net/grnet/synnefo/ubuntu <UBUNTU_VERSION> main
deb-src http://ppa.launchpad.net/grnet/synnefo/ubuntu <UBUNTU_VERSION> main
where <UBUNTU_VERSION> is the system Ubuntu version (e.g. precise)
Update
""""""
.. note:: make sure the GPG public key for the GRNET dev team is added:
* In Debian, make sure the GPG public key for the GRNET dev team is added:
.. code-block:: console
...
...
@@ -43,6 +45,15 @@ Update
otherwise *apt-get update* will produce GPG warnings.
* In Ubuntu, make sure the correct PPA signing key is installed:
.. code-block:: console
$ sudo apt-get install python-software-properties
$ sudo add-apt-repository ppa:grnet/synnefo
Finally:
.. code-block:: console
$ sudo apt-get update
...
...
@@ -51,13 +62,7 @@ Update
Install kamaki
""""""""""""""
.. note:: **versions 0.6.0 - 0.6.1 only:**
The *snf-common* package (available at synnefo apt repository) will be automatically installed as a dependency.
.. note:: **versions 0.6.2 and on:**
Since version 0.6.2, *objpool* replaces *snf-common*. The objpool package is also available at synnefo repository and is automatically installed as a dependency. The *snf-common* dependency is removed.
.. note:: The objpool package is available at synnefo repositories and is automatically installed as a dependency.
.. code-block:: console
...
...
@@ -103,19 +108,6 @@ A more detailed example of using virtual env can be found at the `snf-image-crea
Install objpool (was: snf-common)
"""""""""""""""""""""""""""""""""
.. note:: **versions 0.6.0 - 0.6.1 only**
Package snf-common is part of the synnefo project and used to be a kamaki dependency in versions from 0.6.0 to 0.6.1 to provide a connection pooling mechanism. Users who still run 0.6.0 or 0.6.1 may need to manually install the snf-common package:
.. code-block:: console
$ git clone http://code.grnet.gr/git/synnefo
$ cd synnefo/snf-common
$ ./setup build install
$ cd -
**Version 0.6.2 and on:**
Since 0.6.2, kamaki is based on python-objpool. The objpool package is easy to install from source (even on windows platforms):
.. code-block:: console
...
...
@@ -128,7 +120,7 @@ Since 0.6.2, kamaki is based on python-objpool. The objpool package is easy to i
Install kamaki
""""""""""""""
Kamaki can be downloaded from `here <https://code.grnet.gr/projects/kamaki/files>`_, where users can pick the version they prefer and unzip it locally:
Kamaki can be downloaded from `this location <https://code.grnet.gr/projects/kamaki/files>`_, where users can pick the version they prefer and unzip it locally:
.. code-block:: console
...
...
@@ -143,6 +135,7 @@ or it can be downloaded directly from the git repository:
@@ -175,7 +175,7 @@ Since version 0.6.1 kamaki contains a test suite for the kamaki.clients API. The
After that, users can run "kamaki test" commands to unit-test the prepackaged client APIs. Unit-tests are still experimental and there is a high probability of false alarms due to some of the expected values being hard-coded in the testing code.
In version 0.6.3, a quotaholder client is introduced as an advanced feature. Quotaholder client is mostly used as a client library for accessing a synnefo quota service, but it can also be allowed as a kamaki command set, but setting the quotaholder.cli and quotaholder.url methods:
Since version 0.6.3, a quotaholder client is introduced as an advanced feature. Quotaholder client is mostly used as a client library for accessing a synnefo quota service, but it can also be allowed as a kamaki command set, but setting the quotaholder.cli and quotaholder.url methods:
An other example (4.3.2) showcases how to acquire 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 acquires a new token (with a browser) which has to be set to kamaki.
An other example (4.3.2) showcases how to acquire 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 acquire a new token (with a browser) which has to be set to kamaki.
.. code-block:: console
:emphasize-lines: 1
...
...
@@ -519,6 +518,8 @@ An other example (4.3.2) showcases how to acquire and modify configuration setti
1. pithos (10MB, 2 objects)
2. trash (0B, 0 objects)
.. note:: actual kamaki error messages are more helpful and descriptive.
The following example compares some equivalent calls that run *astakos-authenticate* after a *store-list* 401 failure.
.. code-block:: console
...
...
@@ -617,9 +618,9 @@ Permanent history is implemented as a command group and is common to both the on
Scripting
^^^^^^^^^
Since version 6.2, the history-load feature allows the sequential execution of previously run kamaki commands in kamaki shell.
Since version 6.2, the history-run feature allows the sequential execution of previously run kamaki commands in kamaki shell.
The following kamaki sequence copies and downloads a file from mycontainer1, uploads it to mycontainer2, then undo the proccess and repeats it with history-load
The following kamaki sequence copies and downloads a file from mycontainer1, uploads it to mycontainer2, then undo the proccess and repeats it with history-run
.. code-block:: console
:emphasize-lines: 1,12,19,32
...
...
@@ -663,7 +664,7 @@ The following kamaki sequence copies and downloads a file from mycontainer1, upl
store upload mylocalfile mycontainer2:myfile
Upload completed
The above strategy is still very primitive. Users are advised to take advantage of their os shell scripting capabilities and combine them with kamaki one-command for powerful scripting. Still, the history-load functionality might prove handy for kamaki shell users.
The above strategy is still very primitive. Users are advised to take advantage of their os shell scripting capabilities and combine them with kamaki one-command for powerful scripting. Still, the history-run functionality might prove handy for kamaki shell users.
