Open Stack

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 <rbryant at 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