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
