openstack team mailing list archive

["John Purrier" <john@xxxxxxxxxxxxx>]

The timing of this is interesting, as it comes when there is a lot of
discussion about EasyAPI. I would like to encourage discussions about the
EasyAPI extensibility mechanisms versus the OpenStack API v1.1 extension
mechanism. Jorge, you will need to let folks see the proposed updates to the
OpenStack API for version 1.1.

 

It is clearly important to establish a viable OpenStack Compute API by the
Bexar timeframe. We started the implementation in Austin based on the
Rackspace Cloud Servers 1.0 API, now we need to finish the work. The Austin
work is half finished since we could not create and promote the OpenStack
namespace and still required eucatools to set up and manage a cluster.
Presented for comment is an approach for handling the OpenStack API for
Bexar and Cactus. Additionally, this sets a path for the handoff of the API
specification from Rackspace to OpenStack and the Rackspace Cloud transition
to the OpenStack API.

 

Where we are at:

 

a.       The implementation of the OpenStack API framework is complete, with
the ability to return a "not implemented" indicator if the function is not
available. This may occur due to differences in hypervisor support or due to
work in progress.

 

b.       The current OpenStack API is version 1.0, this matches the version
of the Rackspace Cloud Servers API in production in the cloud.

 

c.       Work needs to be done to setup and publish an OpenStack namespace.
Additionally, the source will need to be updated to return the correct
namespace URL. 

 

d.       Work is in progress to implement a set of tools (think eucatools
functionality) to allow Nova to be set up and administered through the
OpenStack API. Need to verify that this functionality will hit in Bexar.

 

The proposed plan:

 

1.       Bexar will present a version 1.0 OpenStack API based on the 1.0
Rackspace Cloud Servers API. The OpenStack namespace will be set up and
published, and tools will be available that manipulate Nova via the
OpenStack API. Any functionality that is not yet implemented will be
documented in the developer's guide.

 

2.       Rackspace will work to finalize the 1.1 Cloud Servers API spec.
Currently, this is thought of as the next version of the Rackspace Cloud
Servers API, but this should change to be considered the OpenStack 1.1
Compute API. If possible, this work to complete the spec should be complete
by mid-January or so. This spec should assume an OpenStack namespace.

 

3.       With the publication of the 1.1 OpenStack Compute API spec,
OpenStack should publish/highlight the provisions for API extensions. This
will be the supported mechanism for projects to extend the official
OpenStack API (without requiring version changes). Projects that are pushing
to update/extend the OpenStack API will be directed to do it via the
official extension mechanism and target the version 1.1 API. The version 1.0
OpenStack API will not be changed or extended.

 

4.       OpenStack will publish roadmap information stating that the 1.1 API
will be available in April, via the Cactus release.

 

5.       Rackspace will implement the 1.1 OpenStack API spec and deploy
support for it on the current Slicehost codebase. Support will be continued
for the 1.0 Rackspace API through version checking. At the point of
deployment the Rackspace Cloud can claim OpenStack compatibility; timing is
controlled by Rackspace product. Any client development against the Cloud
Servers infrastructure that is 1.1 compatible will be able to run unchanged
once Rackspace transitions from the Slicehost codebase to the Nova codebase.

 

6.       Once the version 1.1 specification is complete, the "ownership" of
the spec will be transferred to OpenStack. Practically, Rackspace will
continue to drive innovation through versioning and extensions, but the
official spec will be under the direction of the OpenStack project and
future contributions from Rackspace and others will follow the standard,
open processes. Rackspace and the community will be able to leverage the
published OpenStack developer's guides and other documentation for having
developers interact with their OpenStack Nova deployments.

 

Comments? 

 

Rick/Thierry, if we have work items for Bexar that are not covered in order
to complete this plan let's highlight them ASAP. Also, can we verify that
the management tools are in progress?

 

John