GitLab

Conflicts:
	snf-cyclades-app/synnefo/plankton/backend.py

Use the vmapi when creating servers. Creete instance RAPI call takes the
configuration url instead all the image parametere. The id and format
of the image are still passed, just for readability and debugging.

Also renamed params_url to config-url.

It survived from wrong merge conflict resolving.

regression appeared from the grouped public network support.

Additional synnefo api to be used by internal synnefo services such as
snf-image/ganeti etc.

`synnefo.api.servers.server_created` signal has been created. The signal
is send for each created server. The signal sender is the created vm and
one argument named `created_vm_params` is passed to the connected
callback functions.

Extend Plankton API, to support listing all non-public images that
are available to the user. This can be done by issuing a GET to
shared-images/ and shared-images/detail.

Extend PoolManager to support extending and shrinking of Pools. Also
add extra option '--size' to pool-modify command.

Do not remove and recreate the NICs of a VM when NICs have not changed.

Implement management command for importing an existing Ganeti instance
into Synnefo. The owner, flavor and image are specified by command line
arguments. Importing will fail if the instance has NICs connected to
non-synnefo networks. The --new-nics flag can be used, to remove all
old NICs and create a new one, belonging to one of the public networks.

ensure that user notes the untrusted image risks before he continues to
flavor selection.

fallback to ip address

also send mode/owner/group for each user's authorized_keys

image model get_meta already takes care of escaping the meta value

methods that used to return user specific information modified to return
arrays of objects based on identified image users. Image space delimited
`users` metadata key is now the primary point to identify existing image
users.

warn user against untrustworthy image owners

fix max height and spacing of public keys list view

Add --filter-by option to server-list, network-list and flavor-list
management commands. The value of this option is a comma-seperated list
of key 'cond' val pairs and, when used, only the DB entries that satisfy all of
the specified conditions are displayed.

The exact keys that can be used are displayed in the help message. Also
when a wrong key is used, all the available keys are displayed to the
error message. No attempt is made to "sanitize" the keys.

Examples:
snf-manage server-list --filter-by "deleted=True,state=STARTED"
snf-manage server-list --filter-by userid=cstavr@grnet.gr,flavor__cpu=2
snf-manage flavor-list --filter-by "ram>=1024,disk<20"