[ovirt-devel] VDSM mom dependancy on RHEL7

[Dan Kenigsberg]

On Wed, Jul 23, 2014 at 12:00:36PM -0400, Adam Litke wrote:
> On 23/07/14 13:18 +0100, Dan Kenigsberg wrote:
> >On Wed, Jul 23, 2014 at 07:05:07AM -0400, Martin Polednik wrote:
> >>----- Original Message -----
> >>> From: "Dan Kenigsberg" <danken at redhat.com>
> >>> To: "Martin Polednik" <mpolednik at redhat.com>, dcaro at redhat.com
> >>> Cc: devel at ovirt.org
> >>> Sent: Wednesday, July 23, 2014 12:19:42 PM
> >>> Subject: Re: [ovirt-devel] VDSM mom dependancy on RHEL7
> >>>
> >>> On Tue, Jul 22, 2014 at 06:36:10PM -0400, Martin Polednik wrote:
> >>> > Hi,
> >>> >
> >>> > I've gone through installing VDSM on RHEL7 host
> >>> > (Red Hat Enterprise Linux Server release 7.0 (Maipo)) and encountered
> >>> > issue with mom:
> >>> >
> >>> > Error: Package: mom-0.4.1-2.el6.noarch (ovirt-3.5-epel)
> >>> >            Requires: python(abi) = 2.6
> >>> >            Installed: python-2.7.5-16.el7.x86_64 (@rhel7)
> >>> >                python(abi) = 2.7
> >>> >                python(abi) = 2.7
> >>> >
> >>> > Repositories used were master, master-snapshots and 3.5 + dependancies.
> >>> > Although it is possible to get it working by getting mom source and
> >>> > rebuilding it on RHEL7, I'd like to know if there is different RHEL7
> >>> > repo or this is mistake in repos.
> >>>
> >>> http://resources.ovirt.org/pub/ovirt-3.5-pre/rpm/el7/ is quite empty,
> >>> I'm afraid.
> >>
> >>The problem actually occurs when getting mom from
> >>http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/
> >
> >mom there
> >http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/mom-0.4.1-0.0.master.20140718.gitfcedb2d.el7.noarch.rpm
> >is of older version than the one in your ovirt-3.5-epel
> >(mom-0.4.1-2.el6.noarch). Try disabling ovirt-3.5-epel repo.
> >
> >Since el6->el7 upgrade should be possible, el7 packages must have a
> >higher n-v-r than their el6 diblings.
> 
> Who is the person that is actually building the mom rpms for the
> release?  It's actually not me :)  I am actually a bit confused about
> how to handle this.  Since mom is actually an upstream project that is
> used by people outside of oVirt releases, I have been maintaining
> upstream packages in Fedora/epel.  We haven't really encountered a
> situation where oVirt needs to ship something different than what is
> upstream (but this may come to pass in the future).  A couple of
> questions...
> 
> 1) Should we even be building mom in the ovirt repos at all?

If Fedora/EPEL is good enough - we'd rather use it, instead of
duplicating the effort.

> 
> 2) If we need to ensure a smooth upgrade between el6 and el7, does
> this mean that I need to bump the el7 version every time I upgrade the
> el6 packages?  This seems strange to me.

It's strange and can be anoying, but that's life on Fedora, too. If the
package in F21 declares itself as older than the one in F20, it won't be
updated on a platform upgrade, and it can even hamper the upgrade
altogether.
When building a new version of a package in Fedora/EPEL you should start
with the devel ("rawhide") branch, then backward in time until the
oldest supported version.
I must admit that I'm too lazy to do that when I need to build only f19,
but in that case I try to bump only the minor number of the release, so
that at least in the next release of f20 things would straighten up.

> I think the better solution
> is to not require a specific version of python (2.6, 2.7, etc) but
> just < 3 until we support python3.

The python version dependency is implicit, since rpm ship with .pyc,
which has a different signature in 2.7.

> 
> 3) We should probably make vdsm depend on a specific version of MOM.
> That way we can upgrade the fedora package but have an ovirt host stay
> on a current stabilized version.

But the downside is that every build - no matter how minute - of mom,
would require a contemporary build of vdsm. Seems painful.
Alternatively, before a new mom is released, it should be tested against
current vdsm. If things break, mom should declare a "Conflicts: vdsm <=
current-vdsm-version"