OpenStackAPI 1-1

= OpenStack API 1.1 =

Current spec lives here now Draft 7/23

The OpenStack API version 1.1 will support a few new features as well as bring parity between the OpenStack Compute API and Rackspace Cloud Servers API. You can find a draft of the spec here: OpenStack Compute DevGuide [[WebHelp latest (DRAFT)]]

New features in the OpenStack API 1.1 include IPv6 support, migration to the OpenStack namespace, and support for API extensions. IPv6 support is a requirement for large scale deployments of openstack. Migration to the OpenStack namespace is a requirement of the OpenStack project so that the primary API is not branded with Rackspace. API Extensions will allow developers to innovate more quickly than the core API is updated by providing a method for developers to add extensions to their local installation ahead of the code being accepted by the OpenStack community as a whole. This should stimulate additional features for the core of OpenStack as extensions can be promoted into the core API after their initial implementation as an extension.

As a side note, some features are still missing from the 1.0 specification, such as file injection, server meta data and limits. File injection supports the ability of API users to specify the content of files on the server upon creation, for example adding an ssh key. Server meta data allows users to provide custom key value pairs to describe a server. Finally, limits allow OpenStack administrators to rate limit and provide absolute limits to users. This allows administrators to protect against malicious or poorly written code from its customers. These features will be completed as a part of the OpenStack API 1.1 implementation. These are probably outside the scope of this blueprint until some work is done on the backend for those features.

Discussion
Please direct all feedback / discussion to the mailing list or the following Etherpad: http://etherpad.openstack.org/osapi1-1

I will maintain this page to reflect the feedback. -GabeWestmaas

IPv6
There are a few areas affected by IPv6 addressses. For now these section and page numbers refer to the PDF Spec.

4.1.2.2. Sharing IPv6 Addresses Servers with the same IPv6 affinity ID can share public and private IPv6 IPs for various high availability and load balancing configurations. To launch an HA server, include the optional ipv6AffinityId attribute matching the ipv6AffinityId attribute of a server you wish to share an IP with. Servers that share the same ipv6AffinityId attribute may share IPv6 addresses from a range of allowable addresses. Contact your provider for details on allowable IPv6 address ranges.

The XML and json responses for some resources are also changing. For example, API 1.0 server details include this XML element:

 Web Head 1 2.1   

Whereas the 1.1 equivalent is:

 Web Head 1 2.1      

Migrate to OpenStack namespace
The namespace is migrating over to "http://docs.openstack.org/compute/api/v1.1".

OS API 1.0 Features
Thoughts and issues around features specified in the RS API 1.0 but missing from the OS API 1.0.

File Injection
This is just an API level exposure of the feature specified in the xs-fileinject blueprint. This feature is also specified in https://blueprints.launchpad.net/nova/+spec/file-injection-at-creation however we just need to make sure it is included in the OS API when the feature is available.

Rate Limiting
We need to identify the current state of this, it seems there is some work done, but not complete. It is likely that any work currently done for this reflects global rate limiting and not per project limiting. Decisions need to be made around project vs account and after that we can decide how to set up limits on a per account/project basis. Until then, this cannot be in the API. A separate blueprint should be set up.

Instance MetaData
This feature allows API users to specify custom key-value pairs about an instance, not to be confused with metadata about a host. Some thought needs to be put into this feature as well. Do we want there to be certain metadata always available here? Do we want instances to have special access to their own metadata without needing the API key? MetaData Blueprint.

Error Codes
It is important to work with the implementor of the error-codes blueprint to ensure the proper propagation of nova errors into http errors. The error-codes blueprint is a dependency of the OpenStack blueprint since the API must translate the error codes correctly.

Related Blueprints
https://blueprints.launchpad.net/nova/+spec/xs-fileinject

https://blueprints.launchpad.net/nova/+spec/error-codes