> ----- Forwarded Message ----- > > From: "Itamar Heim" <ih...@redhat.com> > > To: "Sahina Bose" <sab...@redhat.com> > > Cc: "engine-devel" <engine-devel@ovirt.org>, "VDSM Project > > Development" <vdsm-de...@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-de...@lists.fedorahosted.org > > >> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > > > _______________________________________________ > > > vdsm-devel mailing list > > > vdsm-de...@lists.fedorahosted.org > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > _______________________________________________ > > vdsm-devel mailing list > > vdsm-de...@lists.fedorahosted.org > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel