----- Forwarded Message ----- > From: "Itamar Heim" <iheim(a)redhat.com&gt; > To: "Sahina Bose" <sabose(a)redhat.com&gt; > Cc: "engine-devel" <engine-devel(a)ovirt.org&gt;, "VDSM Project > Development" <vdsm-devel(a)lists.fedorahosted.org&gt; > 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)

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