openstack team mailing list archive

[Vishvananda Ishaya <vishvananda@xxxxxxxxx>]

I've been on vacation for the past month, but I'd like to weigh in on the API discussion.  I think it is fairly clear that we cannot decide on the ec2 api as the "standard" api for nova.  I think that choosing the rackspace/openstack api as the standard api for developers is a poor choice for the following reasons:

1. Ownership of the api hasn't hasn't been transferred yet, so we can discuss new features but not actually add any.

2. The API is based on an existing system that doesn't clearly represent the components that actually exist in the current version of Nova

3. As a canonical versioned API, it will require time to be updated and will therefore slow down new features.  (As an example, look how long it is taking just to go from 1.0 to 1.1)

Ultimately it seems that there is a strong Architectural/Waterfall foundation to the Openstack/Rackspace api.  This may be the best approach for designing a public api that we expose to clients, but I think it is a poor model for actual development work.

I feel very strongly that we need to keep the code easy to extend and prototype, without forcing developers to go through the process of api specs and versioning. I don't think this is going to happen through the OpenStack/Rackspace api, due to the reasons outlined above.  The idea of EasyAPI is simply to expose the existing apis that we have for each component for easy consumption.  This allows us to have a simple command line utility to interact with the code we write for each component separately.

This kind of tool is very important for developers; it allows us to have a means for interacting with the system in development mode and generally contributes to the agile development of components.  The OpenStack API can still exist on top of EasyAPI, and provides us with a good place to handle versioning and official external access points.  It can consume the features of the more agile easy api as they become stable.  I think this gives us the best of both worlds.

As the project matures, it may be that Openstack and EasyAPI become the same, but at the current stage, both seem very important to me.  Keep in mind that the code for EasyApi is fairly simple and is simply using reflection to expose existing python api components via REST to a cli.

Vish


On Jan 1, 2011, at 9:51 PM, John Purrier wrote:

> Jay, API extensions are targeted to be included in the OpenStack Compute 1.1 API release in Cactus. I agree that we have our hands full just getting a functioning 1.0 API done for Bexar.
> 
> -John
> 
> -----Original Message-----
> From: openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jay Pipes
> Sent: Friday, December 31, 2010 5:29 AM
> To: Thierry Carrez
> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Openstack] [RFC] OpenStack API
> 
> On Fri, Dec 31, 2010 at 4:22 AM, Thierry Carrez <thierry@xxxxxxxxxxxxx> wrote:
>> John Purrier wrote:
>>> 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.
>>> [...]
>>> 
>>> 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?
>> 
>>> From where I stand, there were no discussions around this subject at the
>> design summit, and no blueprints filed about API coverage or
>> command-line tools... so I assume nobody is actually working
>> specifically on that. If I'm wrong and someone owns this, please let me
>> know.
>> 
>> The Bexar development window is now closing (January 6th is
>> BranchMergeProposalFreeze), so the Bexar objectives sound a bit
>> optimistic. How about making sure we have a plan and the resources
>> assigned to execute it during the Cactus timeframe ?
> 
> ++
> 
> I'm sorry, but I don't believe it is realistic to do API extensions
> for Bexar.  As Thierry said, no blueprints were filed at the summit on
> API extension, no discussions occurred at the summit about it, and
> although Andy has some example/prototype code, I'm sure he would admit
> that his code was meant, at least so far, to spur discussion and not
> necessarily be merged into trunk right away.
> 
> I concur with Thierry that Cactus would be a better timeframe for
> implementing API extensibility. It would allow for the proper amount
> of discussion on this topic to occur.
> 
> -jay
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp