GitLab

Dockerfile version is now 0.3

The request we have tested so far is a server creation with as few
parameters as possible.

"image info" and "flavor info" implementations are trivial and are
implemented by these methods:
* snf_get_flavor
* snf_get_info

"server info" is implemented by this method:
* snf_get_server
but also requires the following side implementations:
* snf_get_server_volume_links (volume attachments)
* snf_get_server_net_attachments (server nics)

Modifications in the json response template had to be applied in
in snf_get_server and snf_get_server_net_attachments to achieve
OpenStack compatibility

Introduce two new modules:
compute.py: replacement functions will be held there, as well as
    the map of replacements
utils.py: common methods that can be used out of context

Use image id for OS_TPL, flavor id for RESOURCE_TPL
Add a "server info" field in the basic testing script

New features: automatically update and create user proxy

Floating IP pools are not supported by Synnefo. Dummy calls can be
used to override obstacles like this.

Basically, copy and paste from previous snf-occi implementation.
The gist is, if the client does not have a token, advise them to
obtain one from astavoms

Update code and docs as seen fit

In version 0.3, a radically different implementation approach is
chosen. The OOI (Openstack OCCI Interface) is used as the primary
tool for processing and operating OCCI calls. The new package, SOI
(Synnefo OCCI Interface) is a wrapper of OOI. It manages the calls
to Synnefo and adjusts OOI to play with Synnefo, through patching.

They were instances of the same class anyway. Besides, there is
no reason to have too instances, since Synnefo compute client
inherits the methods of the OpenStack client and the present
application uses it specificaly to communicate with a Synnefo API.