Open Stack

On Thu, Sep 04, 2014 at 10:18:04AM -0500, Matt Riedemann wrote:
> 
> >>
> >>  - Changes submitted to nova common code would trigger running of CI
> >>    tests against the external virt drivers. Each virt driver core team
> >>    would decide whether they want their driver to be tested upon Nova
> >>    common changes. Expect that all would choose to be included to the
> >>    same extent that they are today. So level of validation of nova code
> >>    would remain at least at current level. I don't want to reduce the
> >>    amount of code testing here since that's contrary to the direction
> >>    we're taking wrt testing.
> >>
> >>  - Changes submitted to virt drivers would trigger running CI tests
> >>    that are applicable. eg changes to libvirt driver repo would not
> >>    involve running database migration tests, since all database code
> >>    is isolated in nova. libvirt changes would not trigger vmware,
> >>    xenserver, ironic, etc CI systems. Virt driver changes should
> >>    see fewer false positives in the tests as a result, and those
> >>    that do occur should be more explicitly related to the code being
> >>    proposed. eg a change to vmware is not going to trigger a tempest
> >>    run that uses libvirt, so non-deterministic failures in libvirt
> >>    will no longer plague vmware developers reviews. This would also
> >>    make it possible for VMWare CI to be made gating for changes to
> >>    the VMWare virt driver repository, without negatively impacting
> >>    other virt drivers. So this change should increase testing quality
> >>    for non-libvirt virt drivers and reduce pain of false failures
> >>    for everyone.

[snip]

> Even if we split the virt drivers out, libvirt would still be the default in
> the Tempest gate runs right?

Yes, what I'm calling the nova common repository would still need to
have a tempest job that was gating on at least one virt driver as a
sanity check. As mentioned above, I'd pretty much expect that all
current tempest jobs for nova common code would continue unchanged.
IOW, a libvirt job would still be gating, and there'd still be a
number of 3rd party CIs for other virt drivers non-gating too.

The only change in testing jobs would be wrt to the new git repos for
the individual virt drivers. Those would be only running jobs directly
related to the code in those repos. it vmware is tested by a vmware CI
job and libvirt is tested by a libvirt CI job.

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