Open Stack

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.

 

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.

 

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
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
[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
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, and delete the original message. 
Your cooperation is appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20101230/e6d9ef4e/attachment.html>