It seems to me that the tension here is that there are groups who
would really like to use features in newer libvirts that we don't CI
on in the gate. Is it naive to think that a possible solution here is
to do the following:

 - revert the libvirt version_cap flag
 - instead implement a third party CI with the latest available
libvirt release [1]
 - document clearly in the release notes the versions of dependancies
that we tested against in a given release: hypervisor versions (gate
and third party), etc etc

Michael

1: I think that ultimately should live in infra as part of check, but
I'd be ok with it starting as a third party if that delivers us
something faster. I'd be happy enough to donate resources to get that
going if we decide to go with this plan.

On Fri, Aug 8, 2014 at 12:38 AM, Matt Riedemann
<mrie...@linux.vnet.ibm.com> wrote:
>
>
> On 7/18/2014 2:55 AM, Daniel P. Berrange wrote:
>>
>> On Thu, Jul 17, 2014 at 12:13:13PM -0700, Johannes Erdfelt wrote:
>>>
>>> On Thu, Jul 17, 2014, Russell Bryant <rbry...@redhat.com> wrote:
>>>>
>>>> On 07/17/2014 02:31 PM, Johannes Erdfelt wrote:
>>>>>
>>>>> It kind of helps. It's still implicit in that you need to look at what
>>>>> features are enabled at what version and determine if it is being
>>>>> tested.
>>>>>
>>>>> But the behavior is still broken since code is still getting merged
>>>>> that
>>>>> isn't tested. Saying that is by design doesn't help the fact that
>>>>> potentially broken code exists.
>>>>
>>>>
>>>> Well, it may not be tested in our CI yet, but that doesn't mean it's not
>>>> tested some other way, at least.
>>>
>>>
>>> I'm skeptical. Unless it's tested continuously, it'll likely break at
>>> some time.
>>>
>>> We seem to be selectively choosing the continuous part of CI. I'd
>>> understand if it was reluctantly because of immediate problems but
>>> this reads like it's acceptable long-term too.
>>>
>>>> I think there are some good ideas in other parts of this thread to look
>>>> at how we can more reguarly rev libvirt in the gate to mitigate this.
>>>>
>>>> There's also been work going on to get Fedora enabled in the gate, which
>>>> is a distro that regularly carries a much more recent version of libvirt
>>>> (among other things), so that's another angle that may help.
>>>
>>>
>>> That's an improvement, but I'm still not sure I understand what the
>>> workflow will be for developers.
>>
>>
>> That's exactly why we want to have the CI system using newer libvirt
>> than it does today. The patch to cap the version doesn't change what
>> is tested - it just avoids users hitting untested paths by default
>> so they're not exposed to any potential instability until we actually
>> get a more updated CI system
>>
>>> Do they need to now wait for Fedora to ship a new version of libvirt?
>>> Fedora is likely to help the problem because of how quickly it generally
>>> ships new packages and their release schedule but it would still hold
>>> back some features?
>>
>>
>> Fedora has an add-on repository ("virt-preview") which contains the
>> latest QEMU + libvirt RPMs for current stable release - this is lags
>> upstream by a matter of days, so there would be no appreciable delay
>> in getting access to newest possible releases.
>>
>>>>> Also, this explanation doesn't answer my question about what happens
>>>>> when the gate finally gets around to actually testing those potentially
>>>>> broken code paths.
>>>>
>>>>
>>>> I think we would just test out the bump and make sure it's working fine
>>>> before it's enabled for every job.  That would keep potential breakage
>>>> localized to people working on debugging/fixing it until it's ready to
>>>> go.
>>>
>>>
>>> The downside is that new features for libvirt could be held back by
>>> needing to fix other unrelated features. This is certainly not a bigger
>>> problem than users potentially running untested code simply because they
>>> are on a newer version of libvirt.
>>>
>>> I understand we have an immediate problem and I see the short-term value
>>> in the libvirt version cap.
>>>
>>> I try to look at the long-term and unless it's clear to me that a
>>> solution is proposed to be short-term and there are some understood
>>> trade-offs then I'll question the long-term implications of it.
>>
>>
>> Once CI system is regularly tracking upstream releases within a matter of
>> days, then the version cap is a total non-issue from a feature
>> availability POV. It is none the less useful in the long term, for
>> example,
>> if there were a problem we miss in testing, which a deployer then hits in
>> the field, the version cap would allow them to get their deployment to
>> avoid use of the newer libvirt feature, which could be a useful workaround
>> for them until a fix is available.
>>
>> Regards,
>> Daniel
>>
>
> FYI, there is a proposed revert of the libvirt version cap change mentioned
> previously in this thread [1].
>
> Just bringing it up again here since the discussion should happen in the ML
> rather than gerrit.
>
> [1] https://review.openstack.org/#/c/110754/
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Rackspace Australia

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to