----- 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:55:45 AM
> Subject: Re: [vdsm] How to handle qemu 1.3 dep for Gluster Storage Domain
> 
> On 08/12/2013 07:22 PM, Andrew Cathrow wrote:
> >
> > ----- 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 ......
> 
> what do you mean by 'out of luck'.. I thot virt-preview had F17/F18
> repos, no ?

As I said, virt-preview may be an option for F18 as it has a newer version of 
qemu in there but F17's virt-preview doesn't have a new enough version of qemu

> Another Q to answer would be.. Do we support F17 as a valid vdsm host
> for 3.3 ?
> 
> _______________________________________________
> 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