Bug 871804

Summary:	rhevm-dbscripts package is rhevm version independent
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Pavel Stehlik <pstehlik>
Component:	ovirt-engine-setup	Assignee:	Alex Lourie <alourie>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Pavel Stehlik <pstehlik>
Severity:	high	Docs Contact:
Priority:	urgent
Version:	3.1.0	CC:	alourie, bazulay, dyasny, iheim, mgoldboi, oschreib, Rhev-m-bugs, sgrinber, ykaul
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	integration
Fixed In Version:	si24.1	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-12-04 20:03:27 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Pavel Stehlik 2012-10-31 12:51:36 UTC

Description of problem:
 dbscripts should be version locked  (upgrade from 3.0)


[root@ps-ad2-set ~]# rpm -qR rhevm-dbscripts
/bin/bash  
/bin/sh  
rhevm  
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1


Version-Release number of selected component (if applicable):
si22.1

How reproducible:
100%

Steps to Reproduce:
1. yum update rhevm-dbscripts
2.
3.
  
Actual results:
nowadays is upgrade allowed and version is neglected

Expected results:
version should corresponds with rhevm

Additional info:

Comment 1 Itamar Heim 2012-10-31 14:51:59 UTC

need to make sure dbscripts of 3.1 requires rhevm 3.1?

Comment 2 Alex Lourie 2012-10-31 15:34:05 UTC

In 3.1 rhevm-dbscripts is already a part of rpm lock list. Do we want to backport this?

Comment 3 Barak 2012-11-01 09:57:56 UTC

This is actually not a bug.
It was meant initially to enable installation of a db independently.

I would close this BZ per comment #2 above.

Itamar ?

Comment 4 Itamar Heim 2012-11-01 11:25:28 UTC

1. but we version locked it in another bug.
2. the current problem is a 3.0 customer will get the dbscripts package of 3.1 via yum update. we need the 3.1 dbscripts package to require rhevm-3.1 to not be deployed on 3.0 environments (which would blow up for them if they try to recover their system with them via backup/createdb/restore/etc.)
3. if we want to allow deploying this rpm on separate machines, you can conflict with <=3.1 instead of requiring it.

Comment 5 Alex Lourie 2012-11-01 11:51:04 UTC

To provide any solution to 3.0 we would have to backport dbscripts rpm locking to the 3.0 (and deliver it in a Z stream).

Is that what's requested? Otherwise, the issue is not relevant for 3.1 -> forward installations.

Comment 6 Itamar Heim 2012-11-01 14:42:02 UTC

(In reply to comment #5)
> To provide any solution to 3.0 we would have to backport dbscripts rpm
> locking to the 3.0 (and deliver it in a Z stream).

this will not solve the issue, since a 3.0 customer will get by then the 3.1 rpm.

> 
> Is that what's requested? Otherwise, the issue is not relevant for 3.1 ->
> forward installations.

the issue is relevant to prevent a 3.0 customer from getting the 3.1 version of the rpm.

Comment 7 Alex Lourie 2012-11-02 12:23:20 UTC

Fix posted for review upstream: http://gerrit.ovirt.org/#/c/8991/

Comment 8 Alex Lourie 2012-11-03 21:58:37 UTC

fix posted for review downstream: https://gerrit.eng.lab.tlv.redhat.com/#/c/3063/

Comment 9 Ofer Schreiber 2012-11-04 09:50:05 UTC

The problem I see with this fix:
Assume we have a customer with 3.0 dbscripts package. this package is not locked.
now, we release 3.1, and 3.1 dbscripts is available via yum.

if the new package is requries rhevm >= 3.1 , we will have a big problem, as we will break his you dependency tree, since a regular `yum update` command will try to upgrade dbscripts, but he won't be able to find rhevm>= 3.1 (since it's locked).