Open Stack

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