atom feed5 messages in net.launchpad.lists.openstack[Openstack] Third Party APIs
FromSent OnAttachments
Vishvananda IshayaMay 17, 2012 11:18 am 
Andy EdmondsMay 17, 2012 11:57 am 
Vishvananda IshayaMay 17, 2012 3:10 pm 
Doug DavisMay 18, 2012 11:00 am 
Vishvananda IshayaMay 18, 2012 3:07 pm 
Subject:[Openstack] Third Party APIs
From:Vishvananda Ishaya (
Date:May 17, 2012 11:18:19 am

Hello Everyone,

In the ppb meeting last week[1] we discussed third party apis and decided that
the policy is not to include them in core. Specifically the motion that passed

An OpenStack project will support an official API in it's core implementation
(the OpenStack API). other APIs will be implemented external to core. the core
project will expose stable, complete, performant interfaces so that 3rd party
APIs can be implemented in a complete and performant manner.

So now that we have settled on a long term goal for third party apis, we need to
deal with the short term. We do have a stable interface in Nova in the form of
the OpenStack API but it remains to be seen whether it is complete and
performant enough to allow other apis to be layered on top of it.

Ultimately, I would like to see a stable internal python api that the other apis
could speak through (including the OpenStack api layer), but it will probably
take a while to get there. In the short term I see three possibilities for third
party apis.

1 Proxy Layer

This is the approach being taken by AWSOME, and it is definitely the easiest to
maintain. It has some big advantages, like allowing new apis deployed in a
completely decoupled manner. The main potential drawbacks are performance and an
incomplete mapping of concepts from one api to another. This will most likely
require adding OpenStack api extensions to support some of the extra features in
other apis

2 Separate Project that talks to internal apis

It is possible to write a separate component that imports the compute.api in
nova and uses it directly. This will deal with the performance issues of the
above approach, but it runs the risk of being broken if the compute.api changes
over the course of the release. The advantage of this approach is it will drive
requirements for having a stable/versioned internal api. In this model,
automated testing would be necessary to alert any breakages.

3 Feature Branch in Core

We are doing some work to support Feature and Subsystem branches in our CI
system. 3rd party apis could live in a feature branch so that they can be tested
using our CI infrastructure. This is very similar to the above solution, and
gives us a temporary place to do development until the internal apis are more
stable. Changes to internal apis and 3rd party apis could be done concurrently
in the branch and tested. Once the branch has stabilized, the updates could be
pushed into the internal apis in nova, and the 3rd party api could grow up into
its own project like option 2

It may be that there are other options that I haven't thought of, but regardless
of the approach taken by the various 3rd party apis, I think it is valuable for
us all to work together on stabilizing the internal apis. I'd like the ec2 api
to be able to live separately as well.