openstack team mailing list archive

["John Purrier" <john@xxxxxxxxxxxxx>]

Good discussion, and an overwhelming no vote on requiring OpenStack language
bindings to be first-class constructs and the preferred method for
publishing our programming model.

 

I do believe that we should have/need an aggregation layer for services that
expose multiple services/functions (such as with Nova, containing VM, VV,
VI, and VN services). This will allow us to have a singular endpoint (likely
per geographic region, but that is a subject for follow-on posts) for
OpenStack application developers and sysadmins. This will be versioned, can
supply necessary orchestration, provide transaction support as necessary,
and allow as much concurrency as we choose to allow. We also need a
mechanism to allow service registration and discovery, to allow for
deployment specific topologies (either core services that are not available,
or additional services that have been added).

 

As the programming model, API aggregation, and required logic sits above,
and consumes, the lower level service APIs it makes sense to propose this be
a project on its own. This team could own the API, CLI, and associated
application/sysadmins documentation (working with Anne). This team can also
be the focal point for the creation of the language bindings.

 

Low level service APIs continue to be owned and developed by each of the
service teams.

 

Thoughts?

 



 

-John

 

-----Original Message-----
From: openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx
[mailto:openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx] On Behalf
Of Thierry Carrez
Sent: Tuesday, January 04, 2011 7:53 AM
To: openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] [RFC] OpenStack Programming Model Framework

 

John Dickinson wrote:

> On Jan 3, 2011, at 6:13 PM, John Purrier wrote:

>>  The key concept being proposed is that the developers that will be
interacting with the OpenStack services will not interact directly with the
service API's, but rather will have a set of published language bindings
that define the programming model. This does not preclude direct service
calls, but this will be discouraged in favor of using the bindings. The
bindings will be considered the "Nova API" for all intents and purposes.

> 

> Based on our experience with Cloud Files (HTTP API + 5 language bindings),
I don't agree.

> 

> I think that language bindings are very important, but they add extra
baggage to the project. I would think that we should encourage openstack
users (ie devs) to use provided bindings, but see them as second-class
citizens in relation to the direct API. Language bindings will provide a
good basis for most projects, but the direct API approach will allow the
user (dev) to get better performance or newer features.

> [...]

 

I tend to agree with John D.

 

If you expose language bindings as the recommended way of interacting,

you have to keep them current. That means you have to choose a very

restricted set of languages and commit resources to keeping them current.

 

If the API is exposed as the "pure" way of interacting, you admit that

language bindings can be slightly out of date. You can pick one or two

reference language bindings and maintain them reasonably current, and

leverage language-specific communities to cover for the rest of the

landscape...

 

You end up having better language coverage for less effort. I'm probably

missing the advantage of reducing direct API exposure...

 

-- 

Thierry Carrez (ttx)

Release Manager, OpenStack

 

_______________________________________________

Mailing list: https://launchpad.net/~openstack

Post to     : openstack@xxxxxxxxxxxxxxxxxxx

Unsubscribe : https://launchpad.net/~openstack

More help   : https://help.launchpad.net/ListHelp