Da: arch-boun...@ovirt.org
A: "Dan Kenigsberg" dan...@redhat.com,"Adam Litke" ali...@redhat.com
Cc: engine-de...@ovirt.org,"arch" arch@ovirt.org,"VDSM Project Development"
vdsm-de...@lists.fedorahosted.org
Data: Mon, 03 Feb 2014 08:50:12 +0100
Oggetto: Re: mom RPMs for 3.4
> Il 01/02/2014 23:48, Dan Kenigsberg ha scritto:
> > On Fri, Jan 31, 2014 at 04:56:12PM -0500, Adam Litke wrote:
> >> On 31/01/14 08:36 +0100, Sandro Bonazzola wrote:
> >>> Il 30/01/2014 19:30, Adam Litke ha scritto:
> >>>> On 30/01/14 18:13 +0000, Dan Kenigsberg wrote:
> >>>>> On Thu, Jan 30, 2014 at 11:49:42AM -0500, Adam Litke wrote:
> >>>>>> Hi Sandro,
> >>>>>>
> >>>>>> After updating the MOM project's build system, I have used jenkins to
> >>>>>> produce a set of RPMs that I would like to tag into the oVirt 3.4
> >>>>>> release. Please see the jenkins job [1] for the relevant artifacts
> >>>>>> for EL6[2], F19[3], and F20[4].
> >>>>>>
> >>>>>> Dan, should I submit a patch to vdsm to make it require mom >= 0.4.0?
> >>>>>> I want to be careful to not break people's environments this late in
> >>>>>> the 3.4 release cycle. What is the best way to minimize that damage?
> >>>>>
> >>>>> Hey, we're during beta. I prefer making this requirement explicit now
> >>>>> over having users with supervdsmd.log retate due to log spam.
> >>>>
> >>>> In that case, Sandro, can you let me know when those RPMs hit the
> >>>> ovirt repos (for master and 3.4) and then I will submit a patch to
> >>>> vdsm to require the new version.
> >>>
> >>>
> >>> mom 0.4.0 has been built in last night nightly job [1] and published to
> >>> nightly by publisher job [2]
> >>> so it's already available on nightly [3]
> >>>
> >>> For 3.4.0, it has been planned [4] a beta 2 release on 2014-02-06 so
> >>> we'll include your builds in that release.
> >>
> >> I presume the scripting for 3.4 release rpms will produce a version
> >> without the git-rev based suffix: ie. mom-0.4.0-1.rpm?
> >>
> >> I need to figure out how to handle a problem that might be a bit
> >> unique to mom. MOM is used by non-oVirt users who install it from the
> >> main Fedora repository. I think it's fine that we are producing our
> >> own rpms in oVirt (that may have additional patches applied and may
> >> resync to upstream mom code more frequently than would be desired for
> >> the main Fedora repository). Given this, I think it makes sense to
> >> tag the oVirt RPMs with a special version suffix to indicate that
> >> these are oVirt produced and not upstream Fedora.
> >>
> >> For example:
> >> The next Fedora update will be mom-0.4.0-1.f20.rpm.
> >> The next oVirt update will be mom-0.4.0-1ovirt.f20.rpm.
> >>
> >> Is this the best practice for accomplishing my goals? One other thing
> >> I'd like to have the option of doing is to make vdsm depend on an
> >> ovirt distribution of mom so that the upstream Fedora version will not
> >> satisfy the dependency for vdsm.
> >
> > What is the motivation for this? You would not like to bother Fedora
> > users with updates that are required only for oVirt?
> >
> > Vdsm itself is built, signed, and distributed via Fedora.
> > It is also copied into the ovirt repo, for completeness sake. Could MoM
> > do the same?
>
> IMHO, if we're distributing mom and vdsm rpms through Fedora yum repository
> we should not duplicate it on ovirt yum repository.
> Fedora package is signed and will differ from the one we're shipping within
> ovirt repo (which is unsigned)
> We should provide on resource.ovirt.org only packages not available on
> "downstream" repositories (like nightly builds).why you can't sign your
> rpms???on ovirt web page http://www.ovirt.org/Home you can change:Enhanced
> security: SELinux and Mandatory Access Control for VMs and hypervisor
> with:Enhanced security: SELinux and Mandatory Access Control for VMs and
> hypervisor (but not signed rpms)best regardsa
>
>
> >
> > Dan.
> >
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> _______________________________________________
> Arch mailing list
> Arch@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
_______________________________________________
Arch mailing list
Arch@ovirt.org
http://lists.ovirt.org/mailman/listinfo/arch
