openstack team mailing list archive

[Andy Edmonds <andy@xxxxxxxxxx>]

Hey Vish,
In the case of option 2, can such a isolated component remain under the
'nova' module (e.g. the ec2 module under nova/api/) on the nova repository
or must it be on a separate repository and yet be, via some means, made
easily integrated to the master branch code?

Cheers,

Andy
andy.edmonds.be


On Thu, May 17, 2012 at 8:18 PM, Vishvananda Ishaya
<vishvananda@xxxxxxxxx>wrote:

> 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 is:
>
> *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.
>
> Vish
>
> [1]
> http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-08-20.00.log.txt
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>