Open Stack

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 <rbryant at redhat.com
> > <mailto:rbryant at 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 :|