On Tue, Jul 10, 2018 at 05:01:22PM +0200, Cornelia Huck wrote:
[...]
> Who is, in general, testing which libvirt version? I can think of:
> - libvirt developers, which will probably run libvirt current git, but
> more likely a released QEMU?
> - QEMU (and other related tools) developers, who will probably use QEMU
> current git, but a released libvirt
> - normal (technical) users and (integration) testers, who will probably
> use released versions of libvirt and QEMU
There is another kind of integration tester -- e.g. FWIW, in Nova I've
been advocating to create a CI job that would do the following:
- QEMU from Git
- libvirt from Git
- Nova from Git
Along with:
- Latest QEMU release
- Latest libvirt release
- Nova from Git
With the aim of seeing what explodes in Nova and file bugs (for the
relevant low-leve components) and coordinate with relevant upstream
accordingly.
* * *
Further, Nova's libvirt driver defines several version constants. The
following two are set to a version that is available across a set of
"Linux distributions that matter"[*]
MIN_LIBVIRT_VERSION = (1, 3, 1)
MIN_QEMU_VERSION = (2, 5, 0)
(The above are the minimum required versions _today_.)
And at the start of each development cycle (lasts 6 months), we evaluate
what versions are available and update the version matrix[*]:
NEXT_MIN_LIBVIRT_VERSION = (3, 0, 0)
NEXT_MIN_QEMU_VERSION = (2, 8, 0)
(The above will be the versions for the _upcoming_ development cycle --
sometime end of this year.)
https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix
--
/kashyap
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
