Re: [Openstack] [RFC] OpenStack API

2011-01-08 Thread Sandy Walsh
Hi!

I just read the EasyAPI BP and, from a technical perspective, seems rational 
and sound. The challenge, of course, are the implications for the business side 
of the house. I realize it doesn't make sense to strive for backward 
compatibility to EC2/RS API's from EasyAPI, but perhaps the BP should discuss 
what an API Bridge might look like so we can pull out the existing API services 
and map them to EasyAPI?

Another point of consideration might be unimplemented features at the 
hypervisor level being reflected in the public API. For example, we have 
already added several features on the XenServer side that don't currently have 
sister operations on the KVM side. Should these operations appear in the public 
API? Or, should the choice of hypervisor cause the public API WADL to change? 
Perhaps it's fine to simply tell a stack user Blah feature is not 
implemented for Foo hypervisor?

Just some thoughts.

-Sandy




From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net 
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of 
Thierry Carrez [thie...@openstack.org]
Sent: Wednesday, January 05, 2011 4:38 AM
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] [RFC] OpenStack API

ksan...@doubleclix.net wrote:
 I have added a new blue print
 https://blueprints.launchpad.net/nova/+spec/open-stack-api and
 associated wiki page to capture and make some progress.I have a
 launchpad account from my Ubuntu days.

Hey ksankar,

We already have a blueprint to cover the Openstack API efforts for teh
Bexar release at:

https://blueprints.launchpad.net/nova/+spec/openstack-api-parity

See previous threads in that list: The Openstack API (1.0) support
already exists in the code, it is currently the Rackspace Cloud API.
Version 1.1 of that API (in Cactus) should have an Openstack namespace
and extensibility.

 [...]
 Developing an Open Stack Cloud System-level CLI might be a good start ...

As part of the above spec, Sandy Walsh has a new python-cloudservers
library (and accompanying cloudservers CLI tool) that, with adequate
rebranding, should just be what you're looking for.

--
Thierry Carrez (ttx)
Release Manager, OpenStack

___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
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 
prohibited.
If you receive this transmission in error, please notify us immediately by 
e-mail
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


Re: [Openstack] [RFC] OpenStack API

2011-01-08 Thread Jorge Williams

On Jan 8, 2011, at 9:47 AM, Sandy Walsh wrote:

 Hi!
 
 I just read the EasyAPI BP and, from a technical perspective, seems rational 
 and sound. The challenge, of course, are the implications for the business 
 side of the house. I realize it doesn't make sense to strive for backward 
 compatibility to EC2/RS API's from EasyAPI, but perhaps the BP should discuss 
 what an API Bridge might look like so we can pull out the existing API 
 services and map them to EasyAPI?
 

+1

I'd love for the blueprint to describe the API Bridge.


 Another point of consideration might be unimplemented features at the 
 hypervisor level being reflected in the public API. For example, we have 
 already added several features on the XenServer side that don't currently 
 have sister operations on the KVM side. Should these operations appear in the 
 public API? Or, should the choice of hypervisor cause the public API WADL to 
 change? Perhaps it's fine to simply tell a stack user Blah feature is 
 not implemented for Foo hypervisor?
 

This is a perfect use case for API extensions.  The idea here is that features 
that all hypervisors can support are part of the core API.  Hypervisor specific 
features are written as extensions. Extensions are query-able, so you can 
programmatically detect which extensions are available in a particular 
deployment.  My thoughts are that yes, this would also cause the public API 
WADL to change, but there should still be an extension call that's easy to 
parse and gives an unambiguous indication that an extension is available 
without having to parse the WADL.  The call also points to documentation on the 
extension.

Are there features in Cloud Servers API V1.0 that can't be supported by all 
hypervisors?

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


Re: [Openstack] [RFC] OpenStack API

2011-01-05 Thread Thierry Carrez
ksan...@doubleclix.net wrote:
 I have added a new blue print
 https://blueprints.launchpad.net/nova/+spec/open-stack-api and
 associated wiki page to capture and make some progress.I have a
 launchpad account from my Ubuntu days.

Hey ksankar,

We already have a blueprint to cover the Openstack API efforts for teh
Bexar release at:

https://blueprints.launchpad.net/nova/+spec/openstack-api-parity

See previous threads in that list: The Openstack API (1.0) support
already exists in the code, it is currently the Rackspace Cloud API.
Version 1.1 of that API (in Cactus) should have an Openstack namespace
and extensibility.

 [...]
 Developing an Open Stack Cloud System-level CLI might be a good start ...

As part of the above spec, Sandy Walsh has a new python-cloudservers
library (and accompanying cloudservers CLI tool) that, with adequate
rebranding, should just be what you're looking for.

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack

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


Re: [Openstack] [RFC] OpenStack API

2011-01-04 Thread Jorge Williams
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:

Agreed,

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.

-John

From: 
openstack-bounces+john=openstack@lists.launchpad.netmailto:openstack-bounces+john=openstack@lists.launchpad.net
 [mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf Of 
ksan...@doubleclix.netmailto:ksan...@doubleclix.net
Sent: Tuesday, January 04, 2011 12:37 PM
To: Vishvananda Ishaya
Cc: openstack@lists.launchpad.netmailto: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.

Cheers
k/
 Original Message 
Subject: Re: [Openstack] [RFC] OpenStack API
From: Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com
Date: Tue, January 04, 2011 9:32 am
To: Ed Leafe e...@leafe.commailto:e...@leafe.com
Cc: openstack@lists.launchpad.netmailto: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 
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: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net
Unsubscribe : https

Re: [Openstack] [RFC] OpenStack API

2011-01-04 Thread Jorge Williams
I think I agree with most of what you're saying, but bringing in the discussion 
in the scope and projects thread I would summarize things a little 
differently:

 OpenStack APIs

1.  Each core project will expose one or more HTTP/RESTful interfaces for the 
purpose interacting with the outside world.

2.  These REST interfaces may be consumed by the public (Public API), or 
operators (Management API).  Orchestration and higher level systems should also 
consume these APIs.

3.  Projects may also expose notification interfaces.  These should also be 
based on HTTP/REST (Atom/PubSubHubBub).

4.  The REST APIs will have a minimum set of standards and capabilities -- they 
will all be versioned,  they should all be extensible, and support rate 
limiting,  etc, etc.

Dev APIs

5.  Additionally, there may exist DevAPIs, these APIs are targeted exclusively 
to project developers

6.  DevAPIs help developers build OpenStack components

7.  They need not be RESTful (though they can be), they might leverage other 
protocols, they may be python based, whatever.

8.  DevAPIs should not be exposed outside a project's boundary.  For example, 
if nova needs to interact with swift, it should interact with swift via the 
OpenStack API, never the DevAPI, that's for swift devs only.

-jOrGe W.

On Jan 4, 2011, at 4:29 PM, 
ksan...@doubleclix.netmailto:ksan...@doubleclix.net
 wrote:

Looks like we are converging. Summarizing:

  1.  OpenStack API is the Management  Control Plane for a Cloud 
Infrastructure built using OpenStack components.
  2.  It will be used by cloud service consumers  operators to build higher 
level systems.
  3.  It is REST-ful
  4.  It will have a programming model appropriate for the audience and their 
use cases
  5.  It will be version-ed
  6.  It is a lightweight framework and will have capabilities for service 
components to expose feature sets via declarative sets
  7.  (my proposal) It will be JSON/HTTP
  8.  (my proposal) We should have appropriate media types for the OpenStack 
API services (I have done it for CDMI, so have an idea how it could look like, 
if we decide to go this route)
  9.  We could propose a first iteration at the next summit
  10. A first client implementation could be a CLI for an OpenStack Cloud system

BTW, this is a little different than what is proposed on the OpenStack 
Framework Model thread.
Cheers
k/
P.S : Do we already have a blueprint for this ?
 Original Message 
Subject: Re: [Openstack] [RFC] OpenStack API
From: Jorge Williams 
jorge.willi...@rackspace.commailto:jorge.willi...@rackspace.com
Date: Tue, January 04, 2011 1:39 pm
To: Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com
Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net 
openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net

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:

Agreed,

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.

-John

From: 
openstack-bounces+john=openstack@lists.launchpad.netmailto:openstack-bounces#43;john=openstack@lists.launchpad.net
 [mailto:openstack-bounces+john=openstack@lists.launchpad.net] On Behalf Of 
ksan...@doubleclix.netmailto:ksan...@doubleclix.net
Sent: Tuesday, January 04, 2011 12:37 PM
To: Vishvananda Ishaya
Cc: openstack@lists.launchpad.netmailto: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