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

[Andrew Cathrow]

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

> > >
> > 
> > hosts are installed prior to storage domain definition usually.
> > we need to find a solution to having a qemu > 1.3 for .el6 (or
> > another
> > version of qemu with this feature set).
> > 

> 
> > >> What will be a good way to handle this ?
> > >> Appreciate your response
> > >>
> > >> thanx,
> > >> deepak
> > >>
> > >> _______________________________________________
> > >> vdsm-devel mailing list
> > >> vdsm-devel at lists.fedorahosted.org
> > >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > >
> > > _______________________________________________
> > > vdsm-devel mailing list
> > > vdsm-devel at lists.fedorahosted.org
> > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > 
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel at lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> > 
>