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 [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. > > > > 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 quality. > 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 on it? Mark. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
