When kamaki is in verbose mode and log_data is set to on, if kamaki receives a status different than the expected (e.g., 200 OK), it will exit prematurely, without printing the API call and the server response.

(kamaki)c@g:~$ kamaki --cloud demo project approve 6b32e9ae-9a5f-4b5e-a798-8471e3f65100 --app-id 211 -v
> POST https://accounts.demo.synnefo.org/identity/v2.0/tokens
>   content-length: 74
>   content-type: application/json
>   X-Auth-Token: ...
> data size: 74
< 
200 OK
< data size: 3845
< -             -        -     -   -  - -
No access to project 6b32e9ae-9a5f-4b5e-a798-8471e3f65100
|  To see all projects
|    kamaki project list
|  To see  memberships
|    kamaki membership list
|  403 FORBIDDEN

Tested on kamaki v0.13

This feature will allow to get object metadata without a separate request.

When there are not sufficient quotas to create a new network kamaki raises the following exception:

kamaki network create --name=foo2 -d

kamaki.cli.cmds.errors
Error stack:
File "/usr/local/bin/kamaki", line 9, in
load_entry_point('kamaki==0.13rc3', 'console_scripts', 'kamaki')()
File "/usr/local/lib/python2.7/dist-packages/kamaki/cli/init.py", line 543, in wrap
func(exe, parser)
File "/usr/local/lib/python2.7/dist-packages/kamaki/cli/init.py", line 591, in run_one_cmd
one_cmd.run(cloud, parser)
File "/usr/local/lib/python2.7/dist-packages/kamaki/cli/one_cmd.py", line 113, in run
exec_cmd(executable, parser.unparsed, parser.print_help)
File "/usr/local/lib/python2.7/dist-packages/kamaki/cli/init.py", line 448, in exec_cmd
return instance.main(*cmd_args)
File "/usr/local/lib/python2.7/dist-packages/kamaki/cli/cmds/network.py", line 217, in main
self._run()
File "/usr/local/lib/python2.7/dist-packages/kamaki/cli/cmds/errors.py", line 55, in _raise
log.debug('Error stack:\n%s' % ''.join(format_stack()))

kamaki.cli.cmds.errors
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/kamaki/cli/cmds/errors.py", line 53, in _raise
return func(self, _args, *_kwargs)
File "/usr/local/lib/python2.7/dist-packages/kamaki/cli/cmds/errors.py", line 76, in _raise
func(self, _args, *_kwargs)
File "/usr/local/lib/python2.7/dist-packages/kamaki/cli/cmds/network.py", line 213, in run
self.print(net, self.print_dict)
UnboundLocalError: local variable 'net' referenced before assignment

local variable 'net' referenced before assignment
| <type 'exceptions.UnboundLocalError'>, -d for debug info
Traceback (most recent call last):
File "/usr/local/bin/kamaki", line 9, in
load_entry_point('kamaki==0.13rc3', 'console_scripts', 'kamaki')()
File "/usr/local/lib/python2.7/dist-packages/kamaki/cli/init.py", line 547, in wrap
raise err
kamaki.cli.errors.CLIError: local variable 'net' referenced before assignment

At the moment, kamaki lacks an option to add user related metadata when creating a server. There should be one, as described in the docs. It's possible to add/remove metadata using the server modify command after the server has been created though.

If kamaki is unable to open a configuration file provided with the -c option it will ignore it without complaining. This is not the expected behavior. If ~/.kamakirc does not exist it's OK to ignore the error, but kamaki should fail if it cannot open a configuration file explicitly specified by the user.

I noticed that when registering an image as public, the image is visible to all pithos users but its .meta file is not (and is kept private). If the .meta does not carry more sensitive info than the image itself, I believe it should be handled in the same way as the image as far as permissions are concerned.

X-Account-Group-* Pithos+ API headers (account level) can carry arbitrary values on the left part (key). E.g., X-Account-Group-GroupA, X-Account-Group-GroupB

This values (e.g., GroupA, GroupB) should be ascii strings, encoded as utf-8.

Implement library methods to stream Pithos+ objects.

The term "streaming" to serial downloading and uploading operations (as opposed to threaded operations) with block buffering at client side.

The streaming features will be exposed to "kamaki file upload", "kamaki file download" and "kamaki file cat" CLI commands.

Refs #106

Atm, there's no way (cli or lib) to create a new subnet, which won't have a gateway IP. If the gateway is missing from the JSON request, the subnet is created with a default gateway IP (according to the OpenStack API).

kamaki should provide a way to create a subnet without a gateway, by sending JSON null as the gateway value (as needed by the API).

Why Config.guess_version needs to initialize a new Config object?

Users reported a number of issues related to kamaki help guides and configration behavior:

• In "kamaki --help", the explanation text for the "-c" and "-o" options is inadequate
• Feature an intermediate level of verbosity "-vv" to output HTTP data along with the headers, provided they are not raw (e.g., not the contents of a pithos object).
• Show description for all config options with the "kamaki config list" command ("--describe-options, "--with-description")
• Document all supported config options, including hidden ones
• Allow default cloud to be defined as an environment variable "KAMAKI_DEFAULT_CLOUD". To resolve the default cloud, check if the global.default_cloud option is set before looking for the corresponding environment variable
• Remove the reportedly confusing separator between the HTTP send and receive logs

Kamaki should print the public url of a file, when it's uploaded using the --public flag. As it is now, uploading and sharing a file is a two action process, because you have to run a file info command too.

kamaki file upload awesome_file.jpg container_name --public
kamaki file info /container_name/awesome_file.jpg

• Document how kamaki finds its certificates right now.
• Document how package managers set system-wide certificates [1].
• Document how kamaki clients will patch kamaki to use a specific certificate (with code examples).

[1] http://mercurial.selenic.com/wiki/CACertificates

Current approach

To initialize each service (e.g. compute, object-store) client, the caller has to get an endpoint URL, using the AstakosClient. E.g. to initialize a compute (Cyclades) and an object-store (Pithos) client:

from kamaki.clients.astakos import AstakosClient
from kamaki.clients.cyclades import CycladesClients
from kamaki.clients.pithos import PithosClient

AUTH_URL, TOKEN = ..., ...
astakos = AstakosClient(AUTH_URL, TOKEN)

CYCLADES_URL = astakos.get_service_endpoints('compute')['publicURL']
cyclades = CycladesClient(CYCLADES_URL, TOKEN)

PITHOS_URL = astakos.get_service_endpoints('object-store')['publicURL']
pithos = PithosClient(PITHOS_URL, TOKEN)

Suggested approach

The service type should be provided by the client class and the method for getting the endpoint URL could be simpler so that it can be used by a programmer oblivious to the Account API internals:

from kamaki.clients.astakos import AstakosClient
from kamaki.clients.cyclades import CycladesClients
from kamaki.clients.pithos import PithosClient

AUTH_URL, TOKEN = ..., ...
astakos = AstakosClient(AUTH_URL, TOKEN)

CYCLADES_URL = astakos.get_endpoint_url(CycladesClient.service_type)
cyclades = CycladesClient(CYCLADES_URL, TOKEN)

PITHOS_URL = astakos.get_endpoint_url(PithosClient.service_type)
pithos = PithosClient(PITHOS_URL, TOKEN)

Rational

All service-specific information is stored and managed in one place: the corresponding client class

Another advantage is simplicity without loss in flexibility (e.g. caller can still plug endpoint URLs to initialize a client class)

Last but not least, this approach makes sense to people unaware of the specifics of the Identity API

I'm using kamaki v0.13 and the flag -o log_data=on/off seems to be ignored. I've tried using other options like -o colors or -o ignore_ssl and they work fine.

Kamaki should support configuration options that are defined per cloud
instance.

The [global] section in .kamakirc should be renamed to [default] or
something equivalent and apply as the default values for all clouds.
Any [cloud] section that defines a config option, should circumvent the
default one.

Example config:

[default]
colors = off
log_data = off
log_token = off

[cloud "test1"]
url = https://accounts.demo.synnefo.org/identity/v2.0
token = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
colors = on

[cloud "test2"]
url = https://accounts.demo.synnefo.org/identity/v2.0
token = YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
log_data = on

[cloud "test3"]
url = https://accounts.demo.synnefo.org/identity/v2.0
token = ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
log_token = on
log_data = on

If I set the ca_certs path as follows, kamaki doesn't recognize it.

ca_certs = "/etc/ssl/certs/ca-certificates.crt"

Example that revealed the problem:
kamaki.clients.pithos.PithosClient.container_create(..., project_id=PrID, ...)
calls "container_put" with "project_id=PrID", while the later expects "project=PrID"

Solution: Use "project_id" everywhere.

Note: Backwards compatibility should be kept for at least one version.

Adding indentation in a lot of messages of Kamaki, will make
its output more readable I believe.

For example, kamaki group list could be displayed as such:

user@host:~# kamaki group list
group1:
  - user1
  - user2
group2:
  - user1
  - user3

Another area that could benefit from indentation is file listing operations:

user@host:~# kamaki file list
       0B aaaa
        D dir1/
        D    dir2/
 12.22KiB       dir2/file5
 13.23KiB    dir1/file1
  2.42KiB    dir1/file2
  4.43KiB file3
  2.11KiB file4

Problem: kamaki CLI and library will connect through https without any SSL Authentication. This is due to the use of Pythons httplib by the underlying objpool package, which provides pooled http/https connections to kamaki and astakosclient.

Solution:

• Patch the module objpool.http to provide SSL Authentication connections, based on this solution: http://code.activestate.com/recipes/577548-https-httplib-client-connection-with-certificate-v/
• Patch HTTPS connections at runtime when invoking kamaki CLI
• Stop execution in case of insecure connections, but let users override this obstacle with a runtime flag and/or a kamaki config option
• Let users provide an SSL certificate with a runtime option and/or with a config option

Note: Python 2.7.9 will natively support SSL Authentication, but until then, kamaki needs to fix this issue with the suggested workaround.

Using latest published kamaki (version 0.13rc6 on pypi), running the following against ~okeanos (production) which is now on Synnefo 0.16:

authURL = 'https://accounts.okeanos.grnet.gr/identity/v2.0'
token = 'https://accounts.okeanos.grnet.gr/identity/v2.0'

from kamaki.clients.astakos import AstakosClient
from kamaki.clients.cyclades import CycladesClient, CycladesBlockStorageClient

from kamaki.clients.utils import https
https.patch_ignore_ssl()

cycladesServiceType = CycladesClient.service_type
blockStorageServiceType = 'object-store'  # CycladesBlockStorageClient.service_type

astakosClient = AstakosClient(authURL, token)
cycladesURL = astakosClient.get_endpoint_url(cycladesServiceType)
print "cycladesURL = %s" % cycladesURL
blockStorageURL = astakosClient.get_endpoint_url(blockStorageServiceType)
print "blockStorageURL = %s" % blockStorageURL
cycladesClient = CycladesClient(cycladesURL, token)
blockStorageClient = CycladesBlockStorageClient(blockStorageURL, token)

produces

cycladesURL = https://cyclades.okeanos.grnet.gr/compute/v2.0
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "devapi.py", line 16, in <module>
    blockStorageURL = astakosClient.get_endpoint_url(blockStorageServiceType)
  File "/Users/loverdos/.virtualenvs/okeanos/lib/python2.7/site-packages/kamaki/clients/astakos/__init__.py", line 66, in wrap
    details=sace.details, status=sace.status)
AstakosClientError: , type = volume

The problem is CycladesBlockStorageClient.service_type has the value volume, but an enumeration of the endpoints:

for endpoint in astakosClient.get_endpoints()['access']['serviceCatalog']:
        print endpoint['type']

astakos_weblogin
account
astakos_auth
identity
compute
admin
vmapi
network
image
object-store

shows that no such endpoint exist. On the other hand, we discover that object-store might be the intended one.

When the filename of a CA certificates file contains non-ascii characters, kamaki reports this error:
Unknown Error: ("'ascii' codec can't encode characters in position X-Y: ordinal not in range(128)", '', 500)
The error is caused by a unicode error. The unicode error is raised by the method "ssl.wrap_socket" in "kamaki.clients.utils.https". It is caused by a known bug of the SSL library: http://bugs.python.org/issue14907

Proposed solution:

• Catch the unicode error early and enhance it with an informative error message, for the kamaki library users.
• Check ca certificates path before initializing any API clients and prohibit it if it contains non-ascii characters.

All kamaki CLI commands should abide to the following rules:

1. All CLI arguments are named, except for ids that identify the basic command objects e.g., user id for user commands, project id for project commands, etc.
2. Error messages are informative and help users solve the problem with other commands, if possible.
3. Error and assisting messages are always printed to the standard error stream.

Some astakos-related commands do not abide to these standards.

When issuing a server create and the option --network is specified, if the given network ID doesn't exist, kamaki erroneously reports:

 (404) No image with id ID found 

The error is something like:

astakosClient.get_endpoint_url(cycladesServiceType)
  File "/usr/lib/python2.6/site-packages/kamaki/clients/astakos/__init__.py", line 66, in wrap
    details=sace.details, status=sace.status)
AstakosClientError: HTTPSClientAuthConnection instance has no attribute 'source_address'

happening under:

$ python -V
Python 2.6.6
$ cat /etc/*-release | uniq
CentOS release 6.5 (Final)

Running the same code with Python 2.7.8 in my MBP laptop + homebrew works fine.

Kamaki fails to write non-ascii characters in the config file. When that happens, kamaki stops dumping the file contents, causing loss of information.

To demonstrate this problem:

$ kamaki config set somevar τιμή
'ascii' codec can't encode characters in position 0-3: ordinal not in range(128)
|  <type 'exceptions.UnicodeEncodeError'>, -d for debug info

It would be useful to have a --hashmap option in kamaki image info,
similar to that of kamaki file info /path/to/file --hashmap.

This should also work for images uploaded by other users, much like
kamaki file info /path/to/file -A UUID --hashmap works.

Note: A service aware error is produced by the service (e.g., a 404 NOT FOUND error), as opposed to service unaware errors like connection failures.

Current situation

When a service aware error occurs, kamaki CLI attempts to guess the cause of the error, by using context information and heuristics on the received error message.

For example, while creating a server, a 404 error may occur. In this context a 404 signify the absence of an image, flavor or network, so a heuristic looks for patterns in the error message that will hopefully help distinguish between these cases.

Problem

The heuristic approach is erroneous for the following reasons:

• error messages of different nature may contain the same patterns causing confusion to kamaki CLI
• error messages may be modified on service software updates, rendering heuristics ineffective
• different error messages may be used on different deployments (e.g., errors in other languages), thus heuristics will not work even if the service software is not updated

Proposed approach

Prepare and attempt the request with as few API calls as possible
If an error occurs
....Use context information and error codes to find out what the error is about
....If not sure
........Auxiliary API calls to find out
....Create a user-friendly error message with all the information gathered

Error message texts are not used for contextual information mining, although they are usually included at the bottom of the kamaki-generated help message (or in debug mode).

Commands affected

All commands implemented in kamaki.cli.cmds are affected, if they use error message heuristics or they are likely to receive ambiguous service aware errors.

Networking scenarios with kamaki library:

• connect and disconnect to networks
• create, attach, detach and destroy IPs
• use network-related blockers
• handle network connections while dealing with VMs

Quotas and projects:

• check quotas and identify projects (orthogonal to other examples)
• move resources between projects
• manage project subscriptions

Installation:

• update python link in windows

As discussed by @vkoukis some time ago, Kamaki should escape all control characters from data received by the user/server.

Here is a proof of concept demonstrating the problem:

root@snf-196067:~# kamaki server list
12 Test
root@snf-196067:~# kamaki server create --name $(echo -e "\b\b\b\b\b\b\b\\b\b\bDELETED") --flavor-id 1 --image-id c7b2acd4-bf23-4759-a40f-c814e8308fc4
root@snf-196067:~# kamaki server list
12 Test                                                                                            DELETED

I've tested this with servers/volumes/files and it works in all three of them, so I believe it's a global problem across Kamaki.

Current syntax:

$ kamaki file upload <sourceFile> <targetLocation>

Suggested syntax:

$ kamaki file upload <sourceFile> [targetLocation]

where the default target location is /pithos/

Rational:

• Uniform behavior in upload and download
• Suggested behavior is more intuitive

After upgrading to 0.13rc4 I get errors like:

AstakosClientError: _ssl.c:335: No root certificates specified for verification of other-side certificates.

This means every software relying on kamaki breaks on upgrade and must be patched. Can you provide a sensible (= non-breaking) default? If there are certs installed in the system (in well-known locations) can they be detected/used automatically by kamaki and avoid such errors?

bc88c077-d0a0-43fe-8179-ddf33ba9acde Foo Lala
2ae40a39-c68a-45d4-9509-77158dba534c John Doe

roles_links:
id: bc88c077-d0a0-43fe-8179-ddf33ba9acde
roles:
name: Foo Lala
user: select --user 2ae40a39-c68a-45d4-9509-77158dba534c
User Foo Lala with id 2ae40a39-c68a-45d4-9509-77158dba534c is now the current session user
Make Foo Lala the default user for future sessions? [y/N]: N

When trying to upload a file to a container that doesn't exist, kamaki exits with the message Unknown Error: NOT FOUND. I would expect it to behave similarly to all the other 404 errors.

Current output:

d@C:/tmp$ kamaki file upload filename /FAKE_CONTAINER
Unknown Error: NOT FOUND

Desired output:

d@C:/tmp$ kamaki container list /FAKE_CONTAINER
Container "/FAKE_CONTAINER" does not exist
|  To list containers
|    kamaki container list
|  Hint: Use a / to refer to a container (default: /pithos) e.g.,
|  To list contents of container "images"
|    kamaki file list /images
|  To get information on file "my.img" in container "images"
|    kamaki file info /images/my.img
|  404 NOT FOUND itemNotFound (Container does not exist)

Current status

The "wait" functionality can block a process while a call back function returns a specific result. So far this is used to block operations related to VMs (i.e., create, delete, start, shutdown, reboot) and network/ip connections (i.e., port create, port delete, ip detach, network disconnect). So far, wait methods block the process while waiting for a given status to change e.g., while the server status is "BUILD".

The top level method in the "Waiter" class is implemented with two modes, namely "wait while" and "wait until". For example, while creating a VM, the caller can either wait while the VM is in "BUILD" status , or wait until the VM reaches the "ACTIVE" status.

The "wait until" functionality is supported and tested as a generic method, under the name "wait for", but it's not used. Rename "wait for" to "wait until", wherever it is used.

Request

• In library, implement "server_wait_until", "server_wait_while", "port_wait_until" and "port_wait_while" methods. Preserve the the "server_wait" and "port_wait" methods for backward compatibility.
• In CLI, expose the functionality wherever applicable. For better performance, "wait" should default to "wait while", but users should be able to pick the mode they prefer.
• Introduce an optional parameter to "wait until" blocker: a list of statuses which will be used by the blocker to raise an exception if one of them is reached. For example, a "server wait for ACTIVE" operation that fails midway, could stop blocking as soon as an "ERROR" status is reached, instead of waiting to time out.

At the moment, kamaki crashes if it encounters a filename with weird characters.

d@C:/tmp/roz$ echo "This is a kamaki test" > $(dd if=/dev/urandom bs=5 count=1)
1+0 records in
1+0 records out
5 bytes (5 B) copied, 2.2886e-05 s, 218 kB/s
d@C:/tmp/roz$ ls
??(\?
d@C:/tmp/roz$ cat ¬Â\(\\÷ 
This is a kamaki test
d@C:/tmp/roz$ kamaki file upload ¬Â\(\\÷ 
Unknown Error: 'utf8' codec can't decode byte 0xac in position 0: invalid start byte

Kamaki should give its own logger to astakosclient, or set a handler for the default "astakosclient" logger.

In some cases kamaki doesn't properly revert/reset terminal options after using the progress bar.

Using kamaki v0.13:

kamaki image register --name "test" --location /NotExistingContainer/test --upload-image-file test

will mess up the terminal, if the specified container doesn't exist.

If a server is in STOPPED state and a server shutdown is issued for that server, kamaki erroneously returns a server not found message.

root@vm:~# kamaki server list 
67 Testing name

root@vm:~# kamaki server info 67
--- snip ---
status: STOPPED
--- snip ---

root@vm:~# kamaki server shutdown 67
No servers with ID 67
|  to get a list of all servers
|    kamaki server list
|  400 BAD REQUEST badRequest (Cannot perform 'STOP' action while server is in 'STOPPED' state.)

root@vm:~# kamaki server shutdown 67 -v
--- snip ---
< 400 BAD REQUEST
<   content-length: 1228
<   content-language: en-us
<   expires: Tue, 23 Sep 2014 09:08:01 GMT
<   vary: X-Auth-Token,Accept-Language
<   server: gunicorn/0.14.5
<   last-modified: Tue, 23 Sep 2014 09:08:01 GMT
<   connection: close
<   cache-control: no-cache, no-store, must-revalidate, max-age=0
<   date: Tue, 23 Sep 2014 09:08:01 GMT
<   content-type: application/json; charset=UTF-8
< data size: 1228
< -             -        -     -   -  - -
No servers with ID 67
|  to get a list of all servers
|    kamaki server list
|  400 BAD REQUEST badRequest (Cannot perform 'STOP' action while server is in 'STOPPED' state.)

For example, have a look at the properties in the below two cases.

$ kamaki image list -l
[...]
7c8f6173-aba8-455d-afd1-c1968d31de19 Bitnami-joomla
    status: AVAILABLE
    checksum: 4bb46f76c26716c372198612e32396b115615eb4570428c9c034edb74da4cb87
    created_at: 2015-02-17 14:03:20
    disk_format: diskdump
    updated_at: 2015-02-17 14:03:20
    properties:
        partition_table: msdos
        kernel: 3.13.0-36-generic
        osfamily: linux
        description: Ubuntu 14.04.1 LTS
        remote_connection: ssh:port=22,user=bitnami
        gui: No GUI
        sortorder: 7801404
        users: bitnami
        os: ubuntu
        root_partition: 1
        swap: 2:976
    is_snapshot: False
    location: pithos://bbab7241-fc27-4d30-bf30-bf361c60491c/images/bitnami-joomla.disklabel
    container_format: bare
    owner: bbab7241-fc27-4d30-bf30-bf361c60491c ([email protected])
    is_public: True
    deleted_at:
    size: 1.21GiB

$ kamaki image info 7c8f6173-aba8-455d-afd1-c1968d31de19
status: AVAILABLE
name: Bitnami-joomla
is-snapshot: False
checksum: 4bb46f76c26716c372198612e32396b115615eb4570428c9c034edb74da4cb87
description:
updated-at: 2015-02-17 14:03:20
created-at: 2015-02-17 14:03:20
id: 7c8f6173-aba8-455d-afd1-c1968d31de19
deleted-at:
location: pithos://bbab7241-fc27-4d30-bf30-bf361c60491c/images/bitnami-joomla.disklabel
is-public: True
owner: bbab7241-fc27-4d30-bf30-bf361c60491c ([email protected])
disk-format: diskdump
size: 1.21GiB
properties:
    PARTITION_TABLE: msdos
    KERNEL: 3.13.0-36-generic
    OSFAMILY: linux
    DESCRIPTION: Ubuntu 14.04.1 LTS
    REMOTE_CONNECTION: ssh:port=22,user=bitnami
    GUI: No GUI
    SORTORDER: 7801404
    USERS: bitnami
    OS: ubuntu
    ROOT_PARTITION: 1
    SWAP: 2:976
container-format: bare

It's possible to recursively download a directory using the -r flag, e.g.:

d@C:/tmp/mple$ kamaki file download /Test/demo -r
Create local directory demo
/Test/demo/foo --> demo/foo
  download                |████████████████████████████████| 100% - 0s

Unfortunately, if a slash is added at the end of the path name, kamaki crashes.

d@C:/tmp/mple$ kamaki file download /Test/demo/ -r
Failed to access a local file
|  Check if the file exists. Also check if the remote
|  directories exist. All directories in a remote path
|  must exist to succesfully download a container or a
|  directory.
|  To create a remote directory:
|    [kamaki] file mkdir REMOTE_DIRECTORY_PATH
|  [Errno 13] Permission denied: u'//foo'

This was observed in the latest Kamaki (5ede47b2e00c5bdd0916f57c704f2db27095fe2d) from the develop branch.

Support the following console types: 'vnc', 'vnc-ws', 'vnc-wss'

To implement this:

• Add support for these types in "CycladesComputeClient.get_server_console" in "kamaki.clients.cyclades"
• Add an optional "--type" argument in "kamaki server console" command (default: "vnc") so that the respecting client method will be called with the selected console type

Kamaki has the following code in kamaki/clients/init.py:

conn.request(
    method=self.method.upper(),
    url=self.path.encode('utf-8'),
    headers=self.headers,
    body=self.data)
sendlog.info('')
keep_trying = TIMEOUT
while keep_trying > 0:
    try:
        return conn.getresponse()
    except ResponseNotReady:
        wait = 0.03 * random()
        sleep(wait)
        keep_trying -= wait

Why kamaki needs to handle httplib's ResponseNotReady exception?

If kamaki fails to open the log file specified in .kamakirc, it will output all log messages on stderr. This is reproducible with both a file that is on a non-existing path and a filename with wrong permissions.

Output:

root@snf-538967:~# kamaki file list

Failed to open any logging locations, file-logging aborted

kamaki(INFO) 2014-06-03 11:15:41,306

    /usr/bin/kamaki file list

- - -

kamaki.clients.send(INFO) 2014-06-03 11:15:41,388

    - -  -   -     -        -             -

kamaki.clients.send(INFO) 2014-06-03 11:15:41,389

Scan all kamaki code checking for pep8 naming conventions violations and modify accordingly.

In specific:

• remove underscores from package names in kamaki.cli
• shorten long package names in kamaki.cli
• rename underscored classes into CamelCase in kamaki.cli.commands modules
• add or remove leading underscores to internally or externally used classes in kamaki.cli.commands modules
• rename classes to achieve uniformity in names where necessary, with respect to backwards compatibility
• localize the use of global, underscore-prefixed variables in kamaki.cli modules. This required modification of some CLI methods which rely on the use of global variables. Remove variables that are rendered unnecessary after the changes.
• rename CamelCase methods to underscored_methods in kamaki.cli.commands
• rename leading underscore from methods used outside of the scope of the module of declaration in kamaki.cli modules
• Push up in hierarchy commonly used member variables in kamaki.cli.command_tree and kamaki.cli.cyclades

Note: The package names kamaki.cli.commands and kamaki.cli.command_tree may be changed to kamaki.cli.cmds and kamaki.cli.cmd_tree respectively. Use this to make sense of the list above when some (but not all) renaming has been applied.

We should set CACERTS_DEFAULT_PATH to '/etc/ssl/certs/ca-certificates.crt' for debian packages.