<html><body>
<p><font size="2" face="sans-serif">Agreed. I thought that one of the action items from that summit session was to make sure the Nova team could, in essence, reverse the previously made decision. Has any investigation on that happened?</font><br>
<font size="2" face="sans-serif"><br>
thanks<br>
-Doug<br>
________________________________________________________<br>
STSM | Standards Architect | IBM Software Group<br>
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com<br>
The more I'm around some people, the more I like my dog.</font><br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF039DFF2F55C8f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Mark McLoughlin ---11/02/2012 12:57:21 PM---Hey Almost exactly 6 months ago, the PPB had a discussion"><font size="2" color="#424282" face="sans-serif">Mark McLoughlin ---11/02/2012 12:57:21 PM---Hey Almost exactly 6 months ago, the PPB had a discussion about 3rd party</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Mark McLoughlin <markmc@redhat.com></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">openstack-tc@lists.openstack.org, </font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Cc: </font><font size="1" face="sans-serif">openstack-dev@lists.openstack.org</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">11/02/2012 12:57 PM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">[openstack-tc] Policy on "3rd party" APIs and Nova</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><font size="2">Hey<br>
<br>
Almost exactly 6 months ago, the PPB had a discussion about 3rd party<br>
APIs after a mailing list discussion on the topic:<br>
<br>
</font></tt><tt><font size="2"><a href="http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-08-20.00.html">http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-08-20.00.html</a></font></tt><tt><font size="2"><br>
</font></tt><tt><font size="2"><a href="https://lists.launchpad.net/openstack-poc/msg00448.html">https://lists.launchpad.net/openstack-poc/msg00448.html</a></font></tt><tt><font size="2"><br>
<br>
The conclusion reached in the meeting was:<br>
<br>
"an OpenStack project will support an official API in it's core <br>
implementation (the OpenStack API). other APIs will be implemented<br>
external to core. the core project will expose stable, complete,<br>
performant interfaces so that 3rd party APIs can be implemented in a<br>
complete and performant manner."<br>
<br>
Let me first qualify that with some of the discussion that lead up to<br>
the policy being voted on:<br>
<br>
<vishy> jbryce: I'm not sure that we can mandate that they must live outside<br>
<vishy> jbryce: unless we are just talking ultimate goal here.<br>
<vishy> jbryce: I agree with the principle that they should be there<br>
<vishy> jbryce: I just don't know if we are technically at the point where they can<br>
<jbryce> vishy: let's work on defining the end state of this as the goal/convention to aim for<br>
<br>
i.e. I think it's fair to say the "policy" was intended to be a<br>
forward-looking "where we want to get to" statement.<br>
<br>
Also, the statement might seem to imply that 3rd party APIs should be<br>
implemented as proxies to the OpenStack REST APIs, but actually the<br>
statement wasn't directing an implementation choice. The other option<br>
discussed was a project exposing a "stable, complete, performant" python<br>
interface for implementing 3rd party APIs either as a plugins or<br>
completely separate services talking to the DB and message bus.<br>
<br>
<br>
Now, what about Nova?<br>
<br>
Nova has an implementation of the EC2 API (a "3rd party API") and,<br>
indeed, has had this since the project began ... even before the<br>
Rackspace CloudServers API became the OpenStack API.<br>
<br>
It seems to me that the EC2 API is a fairly popular feature, generally<br>
works reasonably well and is tested by unit tests, the devstack gate<br>
(using devstack's euca exercise) and smokestack (using nova smoketests).<br>
<br>
It's true there isn't any particular person or group of people<br>
consistently working to improve the EC2 API (can that also be said of<br>
the OpenStack API?) but in Folsom nova/api/ec2 did have 59 commits (4%<br>
of total) by 27 developers (14% of total) and the diffstat was:<br>
<br>
6 files changed, 585 insertions(+), 688 deletions(-)<br>
<br>
Part of that work involved re-factoring some code that was common<br>
between the EC2 and OpenStack APIs.<br>
<br>
Anyway, my take is the EC2 API is a nice feature, we should be proud of<br>
it and we're successfully maintaining it without a terrible amount of<br>
pain.<br>
<br>
<br>
In theory, the PPB's policy decision should have prompted some move by<br>
Nova developers to figure out what "stable, complete, performant"<br>
interface to expose and move the EC2 API to that. Six months have passed<br>
with zero progress, partly because of a lack of interest but mostly<br>
because Nova developers have a lot of other higher priority things on<br>
their plate.<br>
<br>
<br>
The question reared its head again at the Grizzly summit when Joe Gordon<br>
lead this session:<br>
<br>
</font></tt><tt><font size="2"><a href="https://etherpad.openstack.org/grizzly-nova-splitting-out-EC2">https://etherpad.openstack.org/grizzly-nova-splitting-out-EC2</a></font></tt><tt><font size="2"><br>
<br>
The (or at least part of the) motivation for the session was Joe and his<br>
team's work on a Google Compute Engine API implementation:<br>
<br>
</font></tt><tt><font size="2"><a href="https://github.com/cloudscaling/nova-gce">https://github.com/cloudscaling/nova-gce</a></font></tt><tt><font size="2"><br>
<br>
This is implemented quite similarly to the EC2 API so the question<br>
becomes "if new 3rd party APIs can't be added to Nova, how do we expose<br>
the appropriate APIs for those new APIs". It was pretty clear during the<br>
session that we don't have an answer to that.<br>
<br>
<br>
So, to the point - what Nova developers wish to discuss here and at a TC<br>
meeting is how we can make progress.<br>
<br>
Assuming we don't have the "stable, complete, performant" interface<br>
needed for 3rd party APIs, what do we do if the GCE API is proposed for<br>
inclusion in Nova?<br>
<br>
<br>
My opinion - the GCE work looks awesome, it's an exciting new feature<br>
and it's the kind of awesome new feature by awesome developers that we<br>
should be facilitating.<br>
<br>
We have a long term goal of facilitating work like this happening<br>
outside of Nova, but no real sign of that goal coming about in the<br>
medium term.<br>
<br>
We shouldn't let our idealistic long term plans get in the way of<br>
pragmatic, exciting progress happening now.<br>
<br>
Cheers,<br>
Mark.<br>
<br>
<br>
_______________________________________________<br>
OpenStack-TC mailing list<br>
OpenStack-TC@lists.openstack.org<br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc</a></font></tt><tt><font size="2"><br>
<br>
</font></tt><br>
</body></html>