deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eoghan Glynn <egl...@redhat.com>
Subject v1.1 openstack compute API
Date Thu, 26 Jan 2012 11:15:41 GMT

Hi Folks,

Following on from this recently filed JIRA[1], here are some pointers
on the changes needed to update the deltacloud openstack driver to use
the v1.1 openstack compute API as opposed to the 1.0, largely cloudservers-
based, version.

(Note that the v1.1 is effectively synonymous with v2.0, and the
implementation redirects from the former to the latter. I use v1.1
just to reflect the current state of the docco.)

The main focal points of the v1.1 changes were intended to be:

- IPv6 support (version attribute in representation, e.g.
  <ip version="6" addr="::babe:67.23.10.133"/> or
  { "version" : 4, "addr" : "67.23.10.132" })

- migration from rackspace to openstack namespace (and replacing
  cloudservers-originated naming with more generic alternatives,
  e.g. CloudServersAPIFault -> ComputeAPIFault)

- support for an API extensions mechanism to allow new features to be
  added to the API without breaking existing clients[2]

There were other more-fine-grained changes too, for example:

- version negotiation is now based on either decorating the
  Content-Type with a version parameter, or else URI-embedded version
  specifiers as before

- identifiers generally changed from IDs to hrefs, renamed *Id to *Ref,
  for example:
    create_server(..., :imageId => 2, :flavorId => 3)
  becomes:
    create_server(..., :imageRef => 'http://addr/v1.1/images/2',
                       :flavorRef => 'http://addr/v1.1/flavors/3') 

- standard set of query parameters to filter server, image, flavour
  lists
 
- inclusion of self, bookmark, and alternate link in representations

- the pagination mechanism for large collections is slightly different,
  using a marker as opposed to an offset parameter as a cursor into the
  collection

- the limits (user quotas) representation has had minor modifications

- rationalization of server states *may* have some minor impact on the
  deltacloud instance state machine implementation 

- direct access to server and image metadata, via /{server|image}/id/meta

But I'd suspect that a high-level meta-API like deltacloud won't 
neccesarily be impacted by all such changes.

>From an implementation point-of-view, the deltacloud openstack driver
currently depends indirectly on the cloudservers gem - this dependency
would have to be replaced by the openstack-compute gem [3].

The WADL documents (v1.0: [4], v1.1: [5]) for each version give a 
somewhat terse overview of the APIs. More verbose descriptions of the
API are also available on docs.openstack.org (v1.0: [6], v1.1: [7]).

Cheers,
Eoghan

[1] https://issues.apache.org/jira/browse/DTACLOUD-130
[2] http://docs.openstack.org/trunk/openstack-compute/developer/openstack-api-extensions/content/index.html
[3] https://github.com/rackspace/ruby-openstack-compute
[4] http://docs.rackspacecloud.com/servers/api/v1.1/application.wadl
[5] https://github.com/openstack/compute-api/blob/master/openstack-compute-api-1.1/src/os-compute-1.1.wadl
[6] http://docs.rackspacecloud.com/servers/api/v1.0/cs-devguide-20110415.pdf
[7] http://docs.openstack.org/trunk/openstack-compute/developer/openstack-compute-api-1.1/content/index.html

Mime
View raw message