Responses Below
On Jan 4, 2011, at 10:37 AM, <> wrote:

> 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

A huge part of the testing i do as a developer is interacting with the running 
system via the cli.  I currently use the eucatools for this, but this is 
useless for new features that don't fit into the ec2 api cleanly.  Having 
developer cli tools to access the the internal api directly is very useful.

> 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 ?

This one is a little bit muddier in my mind.  I could see them using either the 
internal api or the official versioned api.  I think for plugin components that 
are intended to ultimately be a part of nova, it makes sense to use the 
internal api.  If the component is completely separate it should probably 
interact with the official versioned openstack api.

> If there are two distinct constituents, with clear cut requirements and 
> interfaces, we can work through programming models and appropriate APIs.
> Cheers
> <k/>
> -------- Original Message --------
> Subject: Re: [Openstack] [RFC] OpenStack API
> From: Vishvananda Ishaya <>
> Date: Tue, January 04, 2011 9:32 am
> To: Ed Leafe <>
> Cc:
> 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 api.
> I think this division gives both developers and end users their optimal use 
> case.
> Vish
> 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:
> Post to :
> Unsubscribe :
> More help :

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to