Open Stack

On 09/10/2014 04:11 PM, Jay Pipes wrote:
> On 09/10/2014 05:55 PM, Chris Friesen wrote:

>> If each hypervisor team mostly only modifies their own code, why would
>> there be conflict?
>>
>> As I see it, the only causes for conflict would be in the shared code,
>> and you'd still need to sort out the issues with the shared code even if
>> you split out the individual drivers into separate repos.
>
> a) Sorting out the common code is already accounted for in Dan B's
> original proposal -- it's a prerequisite for the split.

Fair enough.

> b) The conflict Dan is speaking of is around the current situation where
> we have a limited core review team bandwidth and we have to pick and
> choose which virt driver-specific features we will review. This leads to
> bad feelings and conflict.

Why does the core review team need to review virt driver-specific stuff. 
  If we're looking at making subteams responsible for the libvirt code 
then it really doesn't matter where the code resides as long as everyone 
knows who owns it.

> c) It's the impact to the CI and testing load that I see being the
> biggest benefit to the split-out driver repos. Patches proposed to the
> XenAPI driver shouldn't have the Hyper-V CI tests run against the patch.
> Likewise, running libvirt unit tests in the VMWare driver repo doesn't
> make a whole lot of sense, and all of these tests add a
> not-insignificant load to the overall upstream and external CI systems.
> The long wait time for tests to come back means contributors get
> frustrated, since many reviewers tend to wait until Jenkins returns some
> result before they review. All of this leads to increased conflict that
> would be somewhat ameliorated by having separate code repos for the virt
> drivers.


Has anyone considered making the CI tools smarter?  Maybe have a way to 
determine which tests to run based on the code being modified?

If someone makes a change in nova/virt/libvirt there's a limited set of 
tests that make sense to run...there's no need to run xen/hyperv/vmware 
CI tests against it, for example.  Similarly, there's no need to run all 
the nova-scheduler, neutron, server groups, etc. tests.

That way we could give a subteam real responsibility for a specific area 
of the code, and submissions to that area of the code would not be gated 
by bugs in unrelated areas of the code.

Chris