deltacloud-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eoghan Glynn (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DTACLOUD-130) upgrade openstack API from v1.0 to v1.1
Date Thu, 26 Jan 2012 12:09:46 GMT

    [ https://issues.apache.org/jira/browse/DTACLOUD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193767#comment-13193767
] 

Eoghan Glynn commented on DTACLOUD-130:
---------------------------------------

Additional info sent to the dev list: 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

[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
                
> upgrade openstack API from v1.0 to v1.1
> ---------------------------------------
>
>                 Key: DTACLOUD-130
>                 URL: https://issues.apache.org/jira/browse/DTACLOUD-130
>             Project: DeltaCloud
>          Issue Type: Task
>            Reporter: Pádraig Brady
>            Assignee: David Lutterkort
>
> Openstack has removed support for the v1.0 API in the Essex release, which will be in
Fedora 17

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message