Il 03/02/2014 09:35, Amedeo Salvati ha scritto: > > Da: arch-boun...@ovirt.org > A: "Dan Kenigsberg" dan...@redhat.com,"Adam Litke" ali...@redhat.com > Cc: engine-devel@ovirt.org,"arch" a...@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???
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 >> a...@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 _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel