Open Stack

On Wed, Jul 16, 2014 at 04:15:40PM +0200, Sean Dague wrote:

[. . .]

> Anyway, discussion welcomed. My primary concern right now isn't actually
> where we set the bar, but that we set the same bar for everyone.

As someone who tries to test Nova w/ upstream libvirt/QEMU, couple of
points why I disagree with your above comments:


  - From time time I find myself frustrated due to older versions of
    libvirt on CI infra systems: I try to investigate a bug, 2 hours
    into debugging, it turns out that CI system is using very old
    libvirt, alas - it's not in my control. Consequence: The bug
    needlessly got bumped up in priority for investigation, while
    it's already solved in an existing upstream release, just waiting to
    be picked up CI infra.

  - Also, as a frequent tester of libvirt upstream, and a participant
    in debugging the recent Nova snapshots issue mentioned here, the
    comment[1] (by Daniel Berrange) debunks the illusion of "the
    required verison of libvirt should have been released for at least
    30 days" very convincingly in crystal clear language.

  - FWIW, I feel the libvirt version cap[2] is a fine idea to alleviate
    this.

[1] https://review.openstack.org/#/c/103923/ (Comment:Jul 14 9:24 PM)
  -----------------
  "The kind of new features we're depending on in Nova (looking at specs
  proposed for Juno) are not the kind of features that users in any distro
  are liable to test themselves, outside of the context of Nova (or
  perhaps oVirt) applications. eg Users in a distro aren't likely to
  seriously test the NUMA/Hugepages stuff in libvirt until it is part of
  Nova and that Nova release is in their distro, which creates a
  chicken+egg problem wrt your proposal. In addition I have not seen any
  evidence of significant libvirt testing by the distro maintainers
  themselves either, except for the enterprise distros and we if we wait
  for enterprise distros to pick up a new libvirt we'd be talking 1 year+
  of delay. Finally if just having it in a distro is your benchmark,
  then this is satisfied by Fedora rawhide inclusion, but there's
  basically no user testing of that. So if you instead set the
  benchmark to be a released distro, then saying this is a 1 month
  delay is rather misleading, because distros only release once every
  6 months, so you'd really be talking about a 7 month delay on using
  new features. For all these reasons, tieing Nova acceptance to
  distro inclusion of libvirt is a fundamentally flawed idea that does
  not achieve what it purports to achieve & is detrimental to Nova.
  
  I think the key problem here is that our testing is inadequate and we
  need to address that aspect of it rather than crippling our development
  process."
  -----------------

 [2] https://review.openstack.org/#/c/107119/ -- libvirt: add version
     cap tied to gate CI testing

-- 
/kashyap