[openstack-dev] [Nova] New API requirements, review of GCE
markmc at redhat.com
Fri Nov 15 17:32:42 UTC 2013
On Fri, 2013-11-15 at 12:19 -0500, Russell Bryant wrote:
> On 11/15/2013 12:01 PM, Mark McLoughlin 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 . I
> >> think the same sort of standards shold be applied for a new third-party
> >> API, such as the GCE API .
> >> 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.
> > 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.
> Thanks for the comments. Very interesting ...
> A significantly high bar such that having it in the tree isn't a drain
> on nova development (significant commitment by the maintainers, as well
> as solid test coverage) makes sense.
> Would we consider ripping it out if contribution goes down, or testing
> doesn't keep up?
I'd think so, but it should be a pretty serious drop - stuff coming and
going regularly would be more of an issue for users than reduced
> If so, do we apply the same standards to the EC2 API?
> How much time do we give EC2 to get up to this standard before we rip
> it out?
I hadn't understood the EC2 API to be in such a woeful state. Are we
saying the implementation is so bad it's not at all useful for users? Or
that a lack of testing means we see a far higher rather of regressions
than in e.g. the OpenStack API? Or just that we don't see much progress
More information about the OpenStack-dev