Open Stack

On 07/16/2014 05:08 PM, Mark McLoughlin wrote:
> On Wed, 2014-07-16 at 16:15 +0200, Sean Dague wrote:
> ..
>> Based on these experiences, libvirt version differences seem to be as
>> substantial as major hypervisor differences. There is a proposal here -
>> https://review.openstack.org/#/c/103923/ to hold newer versions of
>> libvirt to the same standard we hold xen, vmware, hyperv, docker,
>> ironic, etc.
> 
> That's a bit of a mis-characterization - in terms of functional test
> coverage, the libvirt driver is the bar that all the other drivers
> struggle to meet.
> 
> And I doubt any of us pay too close attention to the feature coverage
> that the 3rd party CI test jobs have.
> 
>> I'm somewhat concerned that the -2 pile on in this review is a double
>> standard of libvirt features, and features exploiting really new
>> upstream features. I feel like a lot of the language being used here
>> about the burden of doing this testing is exactly the same as was
>> presented by the docker team before their driver was removed, which was
>> ignored by the Nova team at the time.
> 
> Personally, I wasn't very comfortable with the docker driver move. It
> certainly gave an outward impression that we're an unfriendly community.
> The mitigating factor was that a lot of friendly, collaborative,
> coaching work went on in the background for months. Expectations were
> communicated well in advance.
> 
> Kicking the docker driver out of the tree has resulted in an uptick in
> the amount of work happening on it, but I suspect most people involved
> have a bad taste in their mouths. I guess there's incentives at play
> which mean they'll continue plugging away at it, but those incentives
> aren't always at play.

I agree. The whole history of the docker driver is sorted. The fact that
it was rushed in, was broken about 4 weeks later, the pleas for getting
the install path in devstack fixed were ignored, and remained basically
broken until it was on threat of removal. I think there is a bad taste
in everyone's mouth around it.

>> It was the concern by the freebsd
>> team, which was also ignored and they were told to go land libvirt
>> patches instead.
>>
>> I'm ok with us as a project changing our mind and deciding that the test
>> bar needs to be taken down a notch or two because it's too burdensome to
>> contributors and vendors, but if we are doing that, we need to do it for
>> everyone. A lot of other organizations have put a ton of time and energy
>> into this, and are carrying a maintenance cost of running these systems
>> to get results back in a timely basis.
> 
> I don't agree that we need to apply the same rules equally to everyone.
> 
> At least part of the reasoning behind the emphasis on 3rd party CI
> testing was that projects (Neutron in particular) were being overwhelmed
> by contributions to drivers from developers who never contributed in any
> way to the core. The corollary of that is the contributors who do
> contribute to the core should be given a bit more leeway in return.
> 
> There's a natural building of trust and element of human relationships
> here. As a reviewer, you learn to trust contributors with a good track
> record and perhaps prioritize contributions from them.

I agree with this. However, I'm not sure the currently 3rd party CI
model fixed the issue. The folks doing CI work at most of these entities
aren't the developers in the core, and are not often even in the same
groups as the developers in the projects.

>> As we seem deadlocked in the review, I think the mailing list is
>> probably a better place for this.
>>
>> If we want to reduce the standards for libvirt we should reconsider
>> what's being asked of 3rd party CI teams, and things like the docker
>> driver, as well as the A, B, C driver classification. Because clearly
>> libvirt 1.2.5+ isn't actually class A supported.
> 
> No, there are features or code paths of the libvirt 1.2.5+ driver that
> aren't as well tested as the "class A" designation implies. And we have
> a proposal to make sure these aren't used by default:
> 
>   https://review.openstack.org/107119

That's interesting, I had not seen that go through. There are also auto
feature selection by qemu, do we need that as well?

> i.e. to stray off the "class A" path, an operator has to opt into it by
> changing a configuration option that explains they will be enabling code
> paths which aren't yet tested upstream.
> 
> These features have value to some people now, they don't risk regressing
> the "class A" driver and there's a clear path to them being elevated to
> "class A" in time. We should value these contributions and nurture these
> contributors.
> 
> Appending some of my comments from the review below. The tl;dr is that I
> think we're losing sight of the importance of welcoming and nurturing
> contributors, and valuing whatever contributions they can make. That
> terrifies me. 

Honestly, I agree, which is why I started this thread mostly on a level
playing field. Because we're now 6 months into the 3rd Party CI
requirements experiment for Nova, and while some things got better, it
feels like the systems are getting ignored a lot. Maybe it's time for a
good think about what part of the 3rd Party CI is being helpful, and
what hasn't been.

Because the desire for test coverage in the gate is currently in direct
opposition to the desire for the gate being "stable" because of the
issues in OpenStack currently outstanding. Which remains a back seat to
something like NFV feature add.

Maybe the pendulum has gone too far.

	-Sean

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140717/d27f3275/attachment.pgp>