[vdsm] How to handle qemu 1.3 dep for Gluster Storage Domain

Deepak C Shetty deepakcs at linux.vnet.ibm.com
Mon Aug 12 12:59:37 UTC 2013


On 08/12/2013 04:51 PM, Andrew Cathrow wrote:
>> ----- Forwarded Message -----
>>> From: "Itamar Heim" <iheim at redhat.com>
>>> To: "Sahina Bose" <sabose at redhat.com>
>>> Cc: "engine-devel" <engine-devel at ovirt.org>, "VDSM Project
>>> Development" <vdsm-devel at 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



More information about the vdsm-devel mailing list