mom RPMs for 3.4

[Sandro Bonazzola]

Il 03/02/2014 09:35, Amedeo Salvati ha scritto:
> 
> Da: arch-bounces at ovirt.org
> A: "Dan Kenigsberg" danken at redhat.com,"Adam Litke" alitke at redhat.com
> Cc: engine-devel at ovirt.org,"arch" arch at ovirt.org,"VDSM Project Development" vdsm-devel at 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???

We're working on that :-)

> 
> 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 at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/arch


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com