On 08/12/2013 06:32 PM, Andrew Cathrow wrote:
----- Original Message -----
From: "Deepak C Shetty" <deepa...@linux.vnet.ibm.com>
Sent: Monday, August 12, 2013 8:59:37 AM
Subject: Re: [vdsm] How to handle qemu 1.3 dep for Gluster Storage Domain
On 08/12/2013 04:51 PM, Andrew Cathrow wrote:
----- Forwarded Message -----
From: "Itamar Heim" <ih...@redhat.com>
To: "Sahina Bose" <sab...@redhat.com>
Cc: "engine-devel" <engine-de...@ovirt.org>, "VDSM Project
Sent: Wednesday, August 7, 2013 1:30:54 PM
Subject: Re: [vdsm] How to handle qemu 1.3 dep for Gluster
On 08/07/2013 08:21 AM, Sahina Bose wrote:
On 08/06/2013 10:48 AM, Deepak C Shetty wrote:
There were 2 learnings from BZ
1) Gluster RPM deps were not proper in VDSM when using Gluster
Domain. This has been partly addressed
by the gluster-devel thread @
and will be fully addressed once Gluster folks ensure their
is friendly enuf for VDSM to consume
just the needed bits. Once that happens, i will be sending a
vdsm.spec.in to update the gluster
deps correctly. So this issue gets addressed in near term.
2) Gluster storage domain needs minimum libvirt 1.0.1 and qemu
libvirt 1.0.1 has the support for representing gluster as a
block device and qemu 1.3 has the
native support for gluster block backend which supports
URI way of representing a gluster
based file (aka volume/vmdisk in VDSM case). Many distros
centos 6.4 in the BZ) won't have qemu
1.3 in their distro repos! How do we handle this dep in VDSM ?
Do we disable gluster storage domain in oVirt engine if VDSM
qemu < 1.3 as part of getCapabilities ?
Do we ensure qemu 1.3 is present in ovirt.repo assuming
always present on VDSM hosts in which
case when VDSM gets installed, qemu 1.3 dep in vdsm.spec.in
install qemu 1.3 from the ovirt.repo
instead of the distro repo. This means vdsm.spec.in will have
1.3 under Requires.
Is this possible to make this a conditional install? That is,
Storage Domain = GlusterFS in the Data center, the bootstrapping
will install the qemu 1.3 and dependencies.
(The question still remains as to where the qemu 1.3 rpms will
RHEL6.5 (and so CentOS 6.5) will get backported libgfapi support so
we shouldn't need to require qemu 1.3 just the appropriate
qemu-kvm version from 6.5
So IIUC this means we don't do anything special in vdsm.spec.in to
handle qemu 1.3 dep ?
If so... what happens when User uses F17/F18 ( as an example) on the
VDSM host.. their repos probably
won't have qemu-kvm which has libgfapi support... how do we handle
Do we just release-note it ?
For Fedora SPEC we'd need to handle use a >=1.3 dependency but for *EL6 it'd need
to be >0.12-whaterver-6.5-has
I would love to hear how. I am waiting on some resolution for this, so
that I can close the 3.3 blocker BZ
For Fedora if I put qemu-kvm >= 1.3 in vdsm.spec.in, then F17/F18 can't
be used as a VDSM host, that may not be acceptable.
vdsm-devel mailing list