[
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
