[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.
Vish
>
> [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