----- Forwarded Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Sahina Bose" <sabose(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>, "VDSM Project
> Development" <vdsm-devel(a)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
> >
>
> 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(a)lists.fedorahosted.org
> >>
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> >
> > _______________________________________________
> > vdsm-devel mailing list
> > vdsm-devel(a)lists.fedorahosted.org
> >
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
>