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

Andrew Cathrow acathrow at redhat.com
Mon Aug 12 13:02:37 UTC 2013



----- 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 

> thanx,
> deepak
> 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 


More information about the vdsm-devel mailing list