On 08/12/2013 07:22 PM, Andrew Cathrow wrote:
----- Original Message -----
From: "Deepak C Shetty" deepakcs@linux.vnet.ibm.com To: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Monday, August 12, 2013 9:39:21 AM Subject: Re: [vdsm] How to handle qemu 1.3 dep for Gluster Storage Domain
On 08/12/2013 06:32 PM, Andrew Cathrow wrote:
----- Original Message -----
From: "Deepak C Shetty" deepakcs@linux.vnet.ibm.com To: vdsm-devel@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@redhat.com > To: "Sahina Bose" sabose@redhat.com > Cc: "engine-devel" engine-devel@ovirt.org, "VDSM Project > Development" vdsm-devel@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
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
I would love to hear how. I am waiting on some resolution for this, so that I can close the 3.3 blocker BZ
For Fedora if I put qemu-kvm >= 1.3 in vdsm.spec.in, then F17/F18 can't be used as a VDSM host, that may not be acceptable.
What options do we have for fedora <f19? virt-preview may be an option for F18 but F17 is out of luck ......
what do you mean by 'out of luck'.. I thot virt-preview had F17/F18 repos, no ? Another Q to answer would be.. Do we support F17 as a valid vdsm host for 3.3 ?