openstack team mailing list archive

["John Purrier" <john@xxxxxxxxxxxxx>]

Hi Chris, I think you answered your concern in your posting. OpenStack
Compute needs to have an open API that is community driven. This obviously
cannot be the Amazon EC2 API, as it is not open. The Rackspace Cloud Servers
API was designated to be the basis for the OpenStack Compute API as it is
published under an open source license, covered most of the virtual machine
provisioning and management functionality, and is syntactically  and
architecturally close to the desired format for the OpenStack project.

 

There is nothing stated or implied that competing APIs should be hindered or
development slowed down. What is stated is that serious progress needs to be
made to have the OpenStack Compute API functional in Bexar. Once we have the
base API complete (matching the RS CS 1.0 spec) we will evolve the API
moving forward in Cactus and beyond.

 

Ideally, we would get folks excited about pushing the OpenStack API forward
and this is where the innovation and evolution will occur. It has become
obvious that a lack of stated direction about the OS API has led to some
confusion, hence a stab at setting a roadmap through Cactus in this RFC. Two
major events need to be happen and be clearly groked by the community; 1)
The basis for the OpenStack API needs to transfer ownership to OpenStack
from Rackspace. This will happen this month, and 2) The OpenStack API needs
a clearly defined mechanism for presenting varying degrees of functionality.
Clouds based on Nova will have a core set of required functions, and a
myriad of optional components. In order to present a well designed and
thought out programming model it is imperative that an extension and
discovery mechanism be added, in addition to versioning (which is
heavy-weight). The extension mechanism is planned to show up in Cactus.

 

Thanks,

 

-John

 

From: Christopher MacGown [mailto:ignoti@xxxxxxxxx] 
Sent: Thursday, December 30, 2010 5:28 PM
To: John Purrier
Cc: openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] [RFC] OpenStack API

 

Hi guys,

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.

 

I've been away in Europe and not as active as I'd like to have been in
OpenStack development because of it. This thread concerns me though. When I
was asked to present the API discussion at the Austin Summit, the only thing
I was told I had to say was that the Rackspace API was becoming the
"canonical" OpenStack one, and that the development of the Amazon API would
continue. So, after my explaining the differences between the OpenStack API
and the Amazon one, the first thing the discussion did was turn to
namespacing and non-standard APIs. From the first summit, the community at
the discussion wanted an ecosystem of APIs to compete with each other and
the "blessed" ones. 

 

I know the goal is to have an API wholly owned by the project that can be
used to allow third-parties to use their already existing software with the
project, considering the disparity of size between the OpenStack user-base
and the largest competitor, does it make sense to focus development on the
Rackspace API? How many of their customers actually use their API (as
opposed to applications that are just an update away from supporting another
one (for instance cyberduck or any of Mike Mayo's apps))? If even 1000% of
the Rackspace cloud userbase used the API, it would be a drop in the bucket
in comparison. So slowing down development of competing APIs (that could be
promoted to canonical ones if they're more popular/better/more
aesthetic/whatever.) seems a waste of community resources.

 

tl;dr - Slowing down development of competing APIs is short-sighted.

 

Christopher