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

Vishvananda Ishaya vishvananda at gmail.com
Tue Nov 19 23:10:45 UTC 2013

On Nov 15, 2013, at 8:28 AM, Russell Bryant <rbryant at redhat.com> 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.
> Thoughts?

I like the idea of giving people +2/a rights to a certain part of the tree.
The ec2 api maintainers could have +2/a rights to api/ec2/*. Occasionally ec2
fixes will need to touch other parts of the tree, and this would require regular
core members to approve. A similar thing could be done for gce and occi when they
are up to snuff.

This seems like a way that we could keep the code together without adding massive
review burden on nova-core.


> [1] https://wiki.openstack.org/wiki/HypervisorSupportMatrix/DeprecationPlan
> [2] https://blueprints.launchpad.net/nova/+spec/gce-api
> -- 
> Russell Bryant
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list