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?
[1] http://jenkins.ovirt.org/view/All/job/manual-build-tarball/179/ [2] http://jenkins.ovirt.org/view/All/job/manual-build-tarball/179/label=centos6... [3] http://jenkins.ovirt.org/view/All/job/manual-build-tarball/179/label=fedora1... [4] http://jenkins.ovirt.org/view/All/job/manual-build-tarball/179/label=fedora2...
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.
[1] http://jenkins.ovirt.org/view/All/job/manual-build-tarball/179/ [2] http://jenkins.ovirt.org/view/All/job/manual-build-tarball/179/label=centos6... [3] http://jenkins.ovirt.org/view/All/job/manual-build-tarball/179/label=fedora1... [4] http://jenkins.ovirt.org/view/All/job/manual-build-tarball/179/label=fedora2...
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.
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.
[1] http://jenkins.ovirt.org/view/Packaging/job/mom_create-rpms/40/ [2] http://jenkins.ovirt.org/view/Publishers/job/publish_ovirt_rpms_nightly/661/ [3] http://resources.ovirt.org/releases/nightly [4] http://www.ovirt.org/OVirt_3.4_release-management
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.
Thoughts?
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?
Dan.
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).
Dan.
Da: arch-bounces@ovirt.org A: "Dan Kenigsberg" danken@redhat.com,"Adam Litke" alitke@redhat.com Cc: engine-devel@ovirt.org,"arch" arch@ovirt.org,"VDSM Project Development" vdsm-devel@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
Il 03/02/2014 09:35, Amedeo Salvati ha scritto:
Da: arch-bounces@ovirt.org A: "Dan Kenigsberg" danken@redhat.com,"Adam Litke" alitke@redhat.com Cc: engine-devel@ovirt.org,"arch" arch@ovirt.org,"VDSM Project Development" vdsm-devel@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch
On 01/02/14 22:48 +0000, Dan Kenigsberg wrote:
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?
Yes, that was my thinking. It seems that oVirt requires updates more frequently than users that use MOM with libvirt directly and the Fedora update process is a bit more heavy than oVirt's at the moment.
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?
If vdsm is finding this to work well than surely I can do the same with MOM. The 0.4.0 build is in updates-testing right now and should be able to be tagged stable in a day or two.
vdsm-devel@lists.fedorahosted.org