Re: [Engine-devel] mom RPMs for 3.4

Da: arch-bounces(a)ovirt.org A: "Dan Kenigsberg" danken(a)redhat.com,"Adam Litke" alitke(a)redhat.com Cc: engine-devel(a)ovirt.org,"arch" arch(a)ovirt.org,"VDSM Project Development" vdsm-devel(a)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 regards a > > > > > > Dan. > > > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > _______________________________________________ > Arch mailing list > Arch(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch