I also agree.   Just to be clear thought, we should make a distinction between 
internal API (devAPI) that's used by the developers of that particular service 
and the management API that may be used by an operator of a service OR by an 
orchestration service and is a proper "OpenStack API" with versioning etc.

-jOrGe W.

On Jan 4, 2011, at 1:05 PM, Vishvananda Ishaya wrote:


This seems like a clear distinction.

On Jan 4, 2011, at 11:02 AM, John Purrier wrote:

Good points, I just deleted my post as you made my points :).

The “devAPI” is valuable for developers/contributors to the OpenStack services 
for all of the reasons Vishy stated in terms of immediacy, access, and easy 
evolution. This should be internal to the project. Having a CLI to drive this 
is a good thing.

The “OpenStack API” is targeted at developers that consume the published 
services (such as provisioning VM’s, Virtual Volumes, Virtual Images, Virtual 
Networks, and Object Storage). These can also be thought of as OpenStack 
application developers and sysadmins. Having a CLI that can be scripted against 
is a good thing. For this audience there is likely a requirement in the API 
stack for orchestration, transactions, and  concurrency that will not be 
exposed through a low level devAPI.


 [mailto:openstack-bounces+john=openstack....@lists.launchpad.net] On Behalf Of 
Sent: Tuesday, January 04, 2011 12:37 PM
To: Vishvananda Ishaya
Cc: openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>
Subject: Re: [Openstack] [RFC] OpenStack API

Good point - this was my concern on "REST API for developers" in the other 
thread. Relative stability, versioning, published API and programming models 
that need to be supported and deprecated systemically and so forth. Plus 
evolutionay concerns like extensibility, feature velocity, ...

Before we even think of devAPi vs internal API, we need to be crisp and clear 
on "For Whom the APIs toll" ...

a)    Developers who develop service components <- Need access to all internals 
and will use python
b)    Cloud Platform developers who develop granular services based on the 
service components <- Are these the clients we are talking about ? Do they need 
a concise programming model and REST API ? If so, what would these actors do ?

If there are two distinct constituents, with clear cut requirements and 
interfaces, we can work through programming models and appropriate APIs.

-------- Original Message --------
Subject: Re: [Openstack] [RFC] OpenStack API
From: Vishvananda Ishaya <vishvana...@gmail.com<mailto:vishvana...@gmail.com>>
Date: Tue, January 04, 2011 9:32 am
To: Ed Leafe <e...@leafe.com<mailto:e...@leafe.com>>
Cc: openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net>

Sure. DevAPI perhaps?

Another point that might help clarify: Each component of Nova exposes an "api" 
to the other components in the system via python methods. You could refer to 
these as the "internal api" for that component. Both the OS api and the EC2 api 
use this internal api, for example, when they are running instance related 
commands. DevAPI (ReflectionAPI/EasyAPI) takes the "internal api" from all of 
the components and sews them up into a rest interface so they can be accessed 
via the cli. I think this is the "best" way for developers to prototype 
components and interact with the system. This is probably not the best way for 
clients to access the system. The "official" api exposed to clients needs to be 
a bit more rigorous with versioning, etc. and can lag behind the internal/dev 
api. The Openstack/Rackspace can continue to be the current versioned official 

I think this division gives both developers and end users their optimal use 


On Jan 4, 2011, at 5:57 AM, Ed Leafe wrote:

> On Jan 3, 2011, at 8:32 PM, Vishvananda Ishaya wrote:
>> 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.
> Is there any chance that you could change the name to something that sounds a 
> little less judgmental? I.e., if it's not EasyAPI, it must be DifficultAPI! 
> Maybe ReflectionAPI or something that describes the approach and not an 
> opinion.
> -- Ed Leafe

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

Mailing list: https://launchpad.net/~openstack
Post to     : 
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

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 
If you receive this transmission in error, please notify us immediately by 
at ab...@rackspace.com, and delete the original message. 
Your cooperation is appreciated.

Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to