GitLab

Conflicts:
	kamaki/version.py
	version

Hotfix 0.13.4

Affects the methods "object_move" and "object_copy" of the class
"PithosRestClient" in "kamaki.clients.pithos", allowing moving and
copying of objects with unicode object or container names.

Closes grnet/kamaki#96

Refs grnet/kamaki#96

Affects the class "kamaki.clients.pithos.PithosClient" and more
specifically the methods "get_object_hashmap", "download_object"
and "download_to_string".

All affected methods will now accept an optional placeholder
"headers" dict as a parameter.

Bump version to 0.13.2next
Conflicts:
	kamaki/version.py
	version

Hotfix 0.13.2

Fixes grnet/kamaki#101

The "create_subnet" library method is modified to accept empty
iterables as gateway values.

The "kamaki subnet create" CLI command is enhanced with a new
argument "--no-gateway".

Fix download of an existing file

Commit 41e4d5b5

 introduced a bug that was triggered when downloading
an existing file. Fix this.
Signed-off-by: Dimitris Aragiorgis <dimitris.aragiorgis@gmail.com>

Some further fixes wrt download

Windows does not allow opening files with mode 'rwb+'. Linux
does but still this is not a proper mode to use.

We should open files with mode 'rb+' in case we resume download
and the file already exists and with mode 'wb+' otherwise.
Signed-off-by: Dimitris Aragiorgis <dimitris.aragiorgis@gmail.com>

In we run:

  os.makedirs("dir1")
  os.makedirs("dir1")

we get OSError: [Errno 17] File exists: 'dir1'

Contrary to that if we run:

  os.makedirs("dir1")
  os.makedirs("dir1/dir2")

it succeeds.

Therefore we must check if our target directory exists before
running makedirs.
Signed-off-by: Dimitris Aragiorgis <dimitris.aragiorgis@gmail.com>

Fix windows directory handing during recursive uploads and downloads 

Signed-off-by: Dimitris Aragiorgis <dimitris.aragiorgis@gmail.com>

A combination of kamaki and Pithos UI usage can lead to a
Pithos state that is inconsistent and does not match
ordinary directory structures.

Specifically, if we have a file under .\dir1\dir2\dir3 and
we upload dir1 recursively from a windows machine, pithos
objects will look like this:

    D dir1/
  10B dir1/dir2/dir3/file
    D dir1\dir2
    D dir1\dir2\dir3

If we traverse the above file structure from Pithos UI two
additional files will be created:

   0B dir1/dir2
   0B dir1/dir2/dir3

The above is a buggy behavior.

This patch introduces the 'kamaki scripts verifyfs' command.
It fixes the above structure in the following manner:

 a) --fix-conflicts will prepare the directory structure
to become consistent by renaming the conflicting objects via adding a
special suffix to them (e.g "_orig_2015-01-02"). Conflicting objects are
objects that already exist in Pithos as file objects but they should be
directory objects instead.

 b) --fix-dir-names will rename all existing directory objects that
contain backslashes in their names, replacing '\' with '/'.

 c) --fix-missing-dirs will create missing intermediate directory
objects.

The --yes option will bypass prompting the end user.
Signed-off-by: Dimitris Aragiorgis <dimitris.aragiorgis@gmail.com>

This will be used for commands that don't fit exactly in the existing
namespaces (file, image, container, etc.).

Here we create a new package 'kamaki.cli.contrib' containing a 'scripts'
module. We activate the new namespace by default.
Signed-off-by: Dimitris Aragiorgis <dimitris.aragiorgis@gmail.com>

With previous commit we fixed upload so that all local paths
are translated to remote paths with '/' as separator.

Here, during download, we translate remote paths to local ones using
os.path.sep as separator and then we use the os.path library to
create or manipulate them.
Signed-off-by: Dimitris Aragiorgis <dimitris.aragiorgis@gmail.com>

Up until now, if a user uploads a directory recursively from
a Windows machine, then the following file structure will be
stored in pithos:

   D dir1/
 10B dir1/dir2/dir3/file
   D dir1\dir2/
   D dir1\dir2\dir3

Downloading this structure from a Linux machine is impossible
because the following directories are created locally:

  dir1
  dir1\dir2
  dir1\dir2\dir3

This way the file cannot be stored under dir1/dir2/dir3 which
does not exist.

Fix this by storing all paths with '/' as a separator in Pithos,
rather than '\'.
Signed-off-by: Dimitris Aragiorgis <dimitris.aragiorgis@gmail.com>

Up until now, during object deletion, we could remove an object even
if other objects with its name as prefix existed (i.e. non empty
directory objects).

With this patch we add an extra warning and prompt the user
before the actual deletion takes place.
Signed-off-by: Dimitris Aragiorgis <dimitris.aragiorgis@gmail.com>

When uploading a directory recursively, intermediate directory
objects are created on the server. Log these actions in stderr with
a 'remote:' prefix so that they do not get misinterpreted as local
actions (mkdir).
Signed-off-by: Dimitris Aragiorgis <dimitris.aragiorgis@gmail.com>

In case no input is given and the user just presses enter,
raw_input() will return an empty string ('') and thus, if we refer
to the first character of the response, an IndexError will be
raised.

Fix this.
Signed-off-by: Dimitris Aragiorgis <dimitris.aragiorgis@gmail.com>

Take care of some behavioral issues

Closes grnet/kamaki#53

Refs grnet/kamaki#53

Refs grnet/kamaki#53

The new runtime argument is "-vv" or "--verbose-with-data". It
has the same effect as "-v -o log_data=on"

Refs grnet/kamaki#53

The command is enriched with two runtime arguments:

"--describe-option-keys": List and describe all option keys, if
    known to kamaki, even if they are not currently active
"--with-description": add description to each option currently
    used

Refs grnet/kamaki#53

Refs grnet/kamaki#53

Refs grnet/kamaki#53

The name of the environment variable is KAMAKI_DEFAULT_CLOUD
Priority from highest to lowest:
    "--cloud" runtime argument
    "default_cloud" config argument
    KAMAKI_DEFAULT_CLOUD environment variable

Print public URL in "kamaki file upload --public"