On Tue, Aug 27, 2013 at 12:13:49PM -0400, Russell Bryant wrote: > On 08/27/2013 12:04 PM, Tim Smith wrote: > > > > On Tue, Aug 27, 2013 at 8:52 AM, Russell Bryant <rbry...@redhat.com > > <mailto:rbry...@redhat.com>> wrote: > > > > > What about publishing the API as blacklisted by default? This way it > > > would be available only to users that enable it explicitly, while > > still > > > supporting the scenario described above. > > > > It still makes no sense to me to merge an API for a feature that can't > > be used. > > > > > > While it's true that there won't be an in-tree driver that supports the > > API for this release cycle, we have a commercial driver that supports it > > (https://github.com/gridcentric/cobalt). > > > > Having the API standardized in Havana would ensure that client support > > is immediately available for our users as well as for the other > > hypervisor vendors should they release a supporting driver in the next 9 > > months. I believe there is precedent for publishing a nova API for those > > purposes. > > IMO, to be the healthiest project we can be, we must focus on what code > is actually a part of Nova. If you'd like to submit your changes for > inclusion into Nova, then we can talk. > > What you are seeing here is a part of the pain of maintaining a fork. I > am not OK with shifting part of that burden on to the upstream project > when it doesn't help the upstream project *at all*. > > When we have supporting code to make the feature usable, then the API > can go in.
Totally agreed with this. Supporting APIs in Nova with no in-tree users, to satisfy the requirements of out of tree drivers should be an explicit non-goal of the community IMHO. If a 3rd party does not wish to contribute their code to Nova codebase, then it is expected that they take on all the burden of doing the extra integration work their fork/branch implies. For a code review POV, I would also not be satisfied doing review of APIs without illustration of an in-tree driver wired up to the wire. Doing API design is hard work, and I've been burnt too many times on other projects adding APIs without in tree users, which then had to be thrown away or replaced when the in-tree user finally arrived. So I would be very much against adding any APIs without in-tree users, even ignoring the fact that I think the "live VM cloning" concept as a whole is flawed. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
