[Openstack] [RFC] OpenStack API

Jorge Williams jorge.williams at rackspace.com
Thu Dec 30 22:46:32 UTC 2010


On Dec 30, 2010, at 3:43 PM, John Purrier wrote:

Hi Sandy, the easy one first… the OpenStack API is versioned, and so is backward compatible. The client will negotiate the highest version it knows about, the API returns will be consistent with that version.

Right.  We create new versions only when we introduce backward compatibility  problems but maintain old versions and the ability to query version info to maintain compatibility.


As for the Easy API…. The on-going discussion is excellent and I believe we are flushing out some core issues. That being said, to date the plan is that there is a canonical OpenStack Compute API, and it is the one derived from the Rackspace Cloud Servers API.

I would like to have Jorge and others join the conversation so that everyone can see what the proposed OpenStack Compute v1.1 extension mechanisms are. As this spec is being finalized perhaps there is an opportunity to merge concepts, if it makes sense. It doesn’t make sense to have divergent efforts at this point IMO, I would like to have full traction on a complete and functional OpenStack API.


I have to admit I'm a little fuzzy on Easy API, but from reading the specs it seems that our ideas are highly compatible.  From my limited understanding it seems that Easy API may be the way by which you can make extensions work in OpenStack.  I'm looking forward to having more conversations on the subject as we move towards transitioning the API to OpenStack.


John

From: Sandy Walsh [mailto:sandy.walsh at rackspace.com]
Sent: Thursday, December 30, 2010 3:27 PM
To: John Purrier; openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
Subject: RE: [Openstack] [RFC] OpenStack API

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 at lists.launchpad.net<mailto:openstack-bounces+sandy.walsh=rackspace.com at lists.launchpad.net> [openstack-bounces+sandy.walsh=rackspace.com at lists.launchpad.net] on behalf of John Purrier [john at openstack.org]
Sent: Thursday, December 30, 2010 3:59 PM
To: openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
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 at rackspace.com<mailto:abuse at rackspace.com>, and delete the original message.

Your cooperation is appreciated.

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20101230/4314905c/attachment.html>


More information about the Openstack mailing list