Open Stack

On Fri, Sep 05, 2014 at 11:29:43AM +0100, John Garbutt wrote:
> On 4 September 2014 23:48, Russell Bryant <rbryant at redhat.com> wrote:
> > On 09/04/2014 06:24 AM, Daniel P. Berrange wrote:
> > If we ignored gerrit for a moment, is rapid increase in splitting out
> > components the ideal workflow?  Would we be better off finding a way to
> > finally just implement a model more like the Linux kernel with
> > sub-system maintainers and pull requests to a top-level tree?  Maybe.
> > I'm not convinced that split of repos is obviously better.
> 
> I was thinking along similar lines.
> 
> Regardless of that, we should try this for Kilo.
> 
> If it feels like we are getting too much driver divergence, and
> tempest is not keeping everyone inline, the community is fragmenting
> and no one is working on the core of nova, then we might have to think
> about an alternative plan for L, including bringing the drivers back
> in tree.
> 
> At least the separate repos will help us firm up the interfaces, which
> I think is a good thing.
> 
> I worry about what it means to test a feature in "nova common, nova
> api, or nova core" or whatever we call it, if there are no virt
> drivers in tree. To some extent we might want to improve the fake virt
> driver for some in-tree functional tests anyways. But thats a separate
> discussion.

I look at what we do with Ironic testing current as a guide here.
We have tempest job that runs against Nova, that validates changes
to nova don't break the separate Ironic git repo. So my thought
is that all our current tempest jobs would simply work in that
way. IOW changes to so called "nova common" would run jobs that
validate the change against all the virt driver git repos. I think
this kind of setup is pretty much mandatory for split repos to be
viable, because I don't want to see us loose testing coverage in
this proposed change.

Having a decent in-tree fake virt driver would none the less be
a nice idea, because it would allow for more complete functional
testing isolated from the risks of bugs in the virt drivers
themselves.

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 :|