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
Development" <vdsm-devel@lists.fedorahosted.org>
Sent: Wednesday, August 7, 2013 1:30:54 PM
Subject: Re: [vdsm] How to handle qemu 1.3 dep for Gluster Storage
Domain

On 08/07/2013 08:21 AM, Sahina Bose wrote:
[Adding engine-devel]

On 08/06/2013 10:48 AM, Deepak C Shetty wrote:
Hi All,
     There were 2 learnings from BZ
https://bugzilla.redhat.com/show_bug.cgi?id=988299

1) Gluster RPM deps were not proper in VDSM when using Gluster
Storage
Domain. This has been partly addressed
by the gluster-devel thread @
http://lists.gnu.org/archive/html/gluster-devel/2013-08/msg00008.html
and will be fully addressed once Gluster folks ensure their
packaging
is friendly enuf for VDSM to consume
just the needed bits. Once that happens, i will be sending a
patch to
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
1.3.

libvirt 1.0.1 has the support for representing gluster as a
network
block device and qemu 1.3 has the
native support for gluster block backend which supports
gluster://...
URI way of representing a gluster
based file (aka volume/vmdisk in VDSM case). Many distros (incl.
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
reports
qemu < 1.3 as part of getCapabilities ?
or
Do we ensure qemu 1.3 is present in ovirt.repo assuming
ovirt.repo is
always present on VDSM hosts in which
case when VDSM gets installed, qemu 1.3 dep in vdsm.spec.in will
install qemu 1.3 from the ovirt.repo
instead of the distro repo. This means vdsm.spec.in will have
qemu >=
1.3 under Requires.

Is this possible to make this a conditional install? That is,
only if
Storage Domain = GlusterFS in the Data center, the bootstrapping
of host
will install the qemu 1.3 and dependencies.

(The question still remains as to where the qemu 1.3 rpms will be
available)
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

https://bugzilla.redhat.com/show_bug.cgi?id=848070

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 it. Do we just release-note it ?

thanx,
deepak

_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to