[openstack-dev] [Nova] New API requirements, review of GCE

Joe Gordon joe.gordon0 at gmail.com
Fri Nov 15 19:31:37 UTC 2013

On Fri, Nov 15, 2013 at 9:01 AM, Mark McLoughlin <markmc at redhat.com> wrote:

> On Fri, 2013-11-15 at 11:28 -0500, Russell Bryant wrote:
> > Greetings,
> >
> > We've talked a lot about requirements for new compute drivers [1].  I
> > think the same sort of standards shold be applied for a new third-party
> > API, such as the GCE API [2].
> >
> > Before we can consider taking on a new API, it should have full test
> > suite coverage.  Ideally this would be extensions to tempest.  It should
> > also be set up to run on every Nova patch via CI.
> >
> > Beyond that point, now is a good time to re-consider how we want to
> > support new third-party APIs.  Just because EC2 is in the tree doesn't
> > mean that has to be how we support them going forward.  Should new APIs
> > go into their own repositories?
> >
> > I used to be against this idea.  However, as Nova's has grown, the
> > importance of finding the right spots to split is even higher.  My
> > objection was primarily based on assuming we'd have to make the Python
> > APIs stable.  I still do not think we should make them stable, but I
> > don't think that's a huge issue, since it should be mitigated by running
> > CI so the API maintainers quickly get notified when updates are
> necessary.
> >
> > Taking on a whole new API seems like an even bigger deal than accepting
> > a new compute driver, so it's an important question.
> >
> > If we went this route, I would encourage new third-party APIs to build
> > themselves up in a stackforge repo.  Once it's far enough along, we
> > could then evaluate officially bringing it in as an official sub-project
> > of the OpenStack Compute program.
> I do think there should be a high bar for new APIs. More than just CI,
> but that there is a viable group of contributors around the API who are
> involved in OpenStack more generally than just maintaining the API in
> question.
> I don't at all like the idea of drivers or APIs living in separate repos
> and building on unstable Nova APIs. Anything which we accept is a part
> of OpenStack should not get randomly made unusable by one contributor
> while other contributors constantly have to scramble to catch up. Either
> stuff winds up being broken too often or we stifle progress in Nova
> because we're afraid to make breaking changes.

the ceilometer plugin for nova hit this, and had to be scrapped.  It hooked
into nova-compute and at one point made nova-compute hang there for minutes
at a time.

I agree, that hooking into our underlying python APIs is a bad idea and a
recipe for disaster. But at the same time I do like having things live in a
separate repo, at the very least until they are mature enough to be pulled
into mainline.

But if we do go with the separate repo solution, what are the issues with
proxying third party APIs on top of OpenStack REST APIs?  Using the REST
APIs would mean we have a stable contract for these third party APIs to
consume, and we also get more feedback about fixing our own API at the same

> I happened to meet Thijs Metsch, the maintainer of OCCI for Nova
> yesterday:
>   https://github.com/tmetsch/occi-os
>   https://wiki.openstack.org/wiki/Occi
> and he described how often he had to fix the API implementation to adapt
> to changes in Nova's API. My advice was to work towards having the API
> be included in Nova (understand that it's a long road and there would be
> a bunch of difficult requirements) or take the less technically
> attractive option of proxying the OCCI API to the stable OpenStack REST
> API.
> For someone like Thijs, choosing a middle road where the API
> implementation is going to be constantly broken is going to suck for him
> and his users.

> Mark.
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131115/0fd5f47e/attachment.html>

More information about the OpenStack-dev mailing list