----- Original Message -----
> From: "Deepak C Shetty" <deepa...@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" <deepa...@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" <ih...@redhat.com>
> >>>>> To: "Sahina Bose" <sab...@redhat.com>
> >>>>> Cc: "engine-devel" <engine-de...@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
> >>>
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=848070
> >> 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 ......




> thanx,
> deepak
> 
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
> 
_______________________________________________
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel

Reply via email to