openstack team mailing list archive

[Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>]

Thanks John. That's a good summary of the plan. I still have a few questions, if you could indulge me ...

Seems like there are two issues being debated, one customer-facing, one Nova-developer-facing:

Customer-facing:
Will OS 1.1 remain backward compatible with 1.0? In other words, is 1.1 truly a point release or a major version increase? A point release says to me it is backwards compatible.

Developer-facing:
The EasyAPI discussion (client-side tools *and* server-side implementation). The assumption here is that EasyAPI could/would be the OS 1.1 implementation. The answer to the customer-facing question will affect this debate.

Separately, there was also a discussion of the "hackability" of the OS API. I think we've seen that with the addition of pause/suspend/diagnostics and admin-only functionality that the current OS API is easily extensible. Are further discussions simply around implementation details? Are we debating a more data-driven implementation vs. a more explicit implementation? Are we debating replacing the current OS 1.0 implementation with EasyAPI? If so, would that be a practical use of resources given the current workload?

Sorry for the million questions, but I think we're getting close to the crux of the matter.

-S



________________________________
From: openstack-bounces+sandy.walsh=rackspace.com@xxxxxxxxxxxxxxxxxxx [openstack-bounces+sandy.walsh=rackspace.com@xxxxxxxxxxxxxxxxxxx] on behalf of John Purrier [john@xxxxxxxxxxxxx]
Sent: Thursday, December 30, 2010 3:59 PM
To: openstack@xxxxxxxxxxxxxxxxxxx
Subject: [Openstack] [RFC] OpenStack API


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



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace. 
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse@xxxxxxxxxxxxx, and delete the original message. 
Your cooperation is appreciated.