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

Deepak C Shetty deepakcs at linux.vnet.ibm.com
Mon Aug 12 13:39:21 UTC 2013


On 08/12/2013 06:32 PM, Andrew Cathrow wrote:
>
> ----- Original Message -----
>> From: "Deepak C Shetty" <deepakcs at linux.vnet.ibm.com>
>> To: vdsm-devel at lists.fedorahosted.org
>> 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" <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 ?
>>
> 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.

thanx,
deepak



More information about the vdsm-devel mailing list