Revision as of 06:21, 5 January 2011

OpenStack REST API

Wiki Page for the blue print https://blueprints.launchpad.net/nova/+spec/open-stack-api

Notes from e-mail chain

OpenStack API is the Management & Control Plane for a Cloud Infrastructure built using OpenStack components.

1. It will be used by cloud service consumers & operators to build higher level systems.
2. It is REST-ful
3. It will have a programming model appropriate for the audience and their use cases
4. It will be version-ed
5. It is a lightweight framework and will have capabilities for service components to expose feature sets via declarative sets
6. Hackability is important - with orthogonal extensibility and discovery mechanisms in the framework (I think we can have a simple capability object/mechanism with a set of declarative name-spaced enumerations)
7. It will be JSON/HTTP
8. We should have appropriate media types for the OpenStack API services
   • I have done it for CDMI, so have an idea how it could look like, if we decide to go this route)
   • Either a MIME for req and resp say Content-type : opstk-req, Content-type : opstk-resp or by function viz. Content-type : os-nova-req, Content-type : os-swift-req
9. We could propose a first iteration at the next summit (April '11)
10. A first client implementation could be a CLI for an OpenStack Cloud system

From Scope/Project thread perspective (Jorge W)

OpenStack REST API (The northbound interfaces)

1. Each core project will expose one or more HTTP/RESTful interfaces for the purpose interacting with the outside world.
2. These REST interfaces may be consumed by the public (Public API), or operators (Management API). Orchestration and higher level systems should also consume these APIs.
3. Projects may also expose notification interfaces. These should also be based on HTTP/REST (Atom/PubSubHubBub).
4. The REST APIs will have a minimum set of standards and capabilities -- they will all be versioned, they should all be extensible, and support rate limiting, etc, etc.

Dev APIs (Internal or southbound APIs)

1. Additionally, there may exist DevAPIs, these APIs are targeted exclusively to project developers
2. DevAPIs help developers build OpenStack components
3. They need not be RESTful (though they can be), they might leverage other protocols, they may be python based, whatever.
4. DevAPIs should not be exposed outside a project's boundary. For example, if nova needs to interact with swift, it should interact with swift via the OpenStack API, never the DevAPI, that's for swift devs only.

Design Notes

1. Should be a superset of Rackspace APIs
   1. Rackspace APIs currently have the goal "Launch and control Cloud Servers™ programmatically using a RESTful API". This interface has a similar goal "Launch and control Cloud Systems programmatically using a RESTful API"
2. Need higher levels abstractions for datacenter/Cloud System, composite application and so forth
3. Storage and Network layer abstractions

Related Blueprint : https://blueprints.launchpad.net/nova/+spec/easy-api