[Engine-devel] mom RPMs for 3.4
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 -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
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.
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
Hi, I just hope you do not forget the EL6 Users out there, or is mom in EPEL or in CentOS main? Am 03.02.2014 08:50, schrieb Sandro Bonazzola:
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).
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
Il 03/02/2014 12:32, Sven Kieske ha scritto:
Hi,
I just hope you do not forget the EL6 Users out there, or is mom in EPEL or in CentOS main?
I'm not forgetting EL6 users :-)
Am 03.02.2014 08:50, schrieb Sandro Bonazzola:
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).
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
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.
participants (4)
-
Adam Litke -
Dan Kenigsberg -
Sandro Bonazzola -
Sven Kieske