Bug 870079 - 3.1 - packaging: vdsm and vdsm-cli conflict causes rhevm-3.0 bootstrap to fail
3.1 - packaging: vdsm and vdsm-cli conflict causes rhevm-3.0 bootstrap to fail
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: vdsm (Show other bugs)
6.3
x86_64 Linux
high Severity high
: rc
: ---
Assigned To: Alon Bar-Lev
Pavel Stehlik
infra
: Regression, ZStream
: 870315 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-25 10:20 EDT by Dafna Ron
Modified: 2014-11-30 10:22 EST (History)
11 users (show)

See Also:
Fixed In Version: vdsm-4.9.6-40.0
Doc Type: Bug Fix
Doc Text:
The VDSM and vdsm-cli packages were changed in 3.1 in a way that creates a conflict with previous packages if VDSM and vdsm-cli are not upgraded at the same yum transaction. rhevm-3.0 tries to upgrade VDSM and vdsm-cli in different yum transactions and fails because of that conflict. Now, vdsm-cli is a dependency of vdsm and is pulled into the vdsm yum transaction, allowing yum to resolve the conflict.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-04 14:13:27 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 35722 master NEW packaging: Branding and spec file changes for downstream Never

  None (edit)
Description Dafna Ron 2012-10-25 10:20:17 EDT
Description of problem:

in the past we did not need to run yum update 'vdsm*' ore remove vdsm-cli before running update for vdsm to succeed update. 

now, when I update 3.0 vdsm to 3.1 vdsm we get a conflict: 

file /usr/share/vdsm/dumpStorageTable.py from install of vdsm-4.9.6-39.0.el6_3.x86_64 conflicts with file from package vdsm-cli-4.9-113.4.el6_3.x86_64

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

4.9-113.4.el6_3.x86_64 -> vdsm-4.9.6-39.0.el6_3.x86_64

How reproducible:

100%

Steps to Reproduce:
1. have a host with 3.0 vdsm
2. run yum update vdsm 
3.
  
Actual results:

we fail on clonflict with vdsm-cli and have to remove the package or run yum update 'vdsm*'


Expected results:

if vdsm-cli is a depended package we should update it automatically
if we can run vdsm without vdsm-cli (since I can remove the package and just update vdsm) I do not see a reason why we should fail the vdsm update on conflict. 

Additional info:


tested with vdsm-4.9-113.4.el6_3.x86_64 ->> vdsm-4.9.6-39.0.el6_3.x86_64

Dependencies Resolved

================================================================================================================================================================================
 Package                                          Arch                               Version                                        Repository                             Size
================================================================================================================================================================================
Updating:
 vdsm                                             x86_64                             4.9.6-39.0.el6_3                               qa-latest                             675 k
Installing for dependencies:
 libvirt-lock-sanlock                             x86_64                             0.9.10-21.el6_3.5                              qa-latest                             125 k
 vdsm-python                                      x86_64                             4.9.6-39.0.el6_3                               qa-latest                              84 k

Transaction Summary
================================================================================================================================================================================
Install       2 Package(s)
Upgrade       1 Package(s)

Total download size: 884 k
Is this ok [y/N]: y
Downloading Packages:
(1/3): libvirt-lock-sanlock-0.9.10-21.el6_3.5.x86_64.rpm                                                                                                 | 125 kB     00:00     
(2/3): vdsm-4.9.6-39.0.el6_3.x86_64.rpm                                                                                                                  | 675 kB     00:00     
(3/3): vdsm-python-4.9.6-39.0.el6_3.x86_64.rpm                                                                                                           |  84 kB     00:00     
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                            25 MB/s | 884 kB     00:00     
Running rpm_check_debug
Running Transaction Test


Transaction Check Error:
  file /usr/share/vdsm/dumpStorageTable.py from install of vdsm-4.9.6-39.0.el6_3.x86_64 conflicts with file from package vdsm-cli-4.9-113.4.el6_3.x86_64
  file /usr/share/vdsm/dumpStorageTable.pyc from install of vdsm-4.9.6-39.0.el6_3.x86_64 conflicts with file from package vdsm-cli-4.9-113.4.el6_3.x86_64
  file /usr/share/vdsm/dumpStorageTable.pyo from install of vdsm-4.9.6-39.0.el6_3.x86_64 conflicts with file from package vdsm-cli-4.9-113.4.el6_3.x86_64
Comment 2 Alon Bar-Lev 2012-10-25 11:30:24 EDT
I just talked with Itamar about this.

Manual update can have conflicts. There is no problem in that. Had this been only that it was left as-is.

However as our bootstrap process of previous vdsm-bootstrap faulty and is not expected to be fixed in rhevm-3.0 engines. We should resolve the conflict <some how>

---

BTW: Dafna, it will be great if you CC discussion people from previous but to new bugs, and copy the relevant discussion.
Comment 3 Alon Bar-Lev 2012-10-25 16:03:35 EDT
commit 21b6561bb24db9c1043adac545f7d18989b7b3a2
Author: Alon Bar-Lev <alonbl@redhat.com>
Date:   Thu Oct 25 18:11:19 2012 +0200

    packaging: add vdsm-cli dependency to vdsm
    
    dumpStorageTable.py was moved[1][2] from vdsm-cli to vdsm package.
    
    As result when updating vdsm without vdsm-cli there is a conflict
    between the old vdsm-cli and the new vdsm packages.
    
    Our old bootstrap code which is shipped with rhevm-3.0 installs
    packages one by one, failing any bootstrap if such conflict exists.
    
    The temporary simplest solution is to pull vdsm-cli into dependency try
    of vdsm package, this dependency will be removed in future when
    newer vdsm-bootstrap be distributed to all rhevm machines.
    
    [1] Ic9dfdc2
    [2] http://gerrit.ovirt.org/1889
    
    Bug-Url: https://bugzilla.redhat.com/show_bug.cgi?id=870079
    Change-Id: Ie62e19d5e1abf9c0e33b11313018a6d59640ae9c
    Signed-off-by: Alon Bar-Lev <alonbl@redhat.com>

diff --git a/vdsm.spec.in b/vdsm.spec.in
index 8dbe5cc..e3fe0eb 100644
--- a/vdsm.spec.in
+++ b/vdsm.spec.in
@@ -79,6 +79,12 @@ Requires: selinux-policy-targeted >= 3.7.19-80.el6
 Requires(pre,preun): policycoreutils-python
 Requires(post): /usr/sbin/saslpasswd2
 
+# backward compatible with older bootstrap code
+# see bug#870079
+# can be removed when rhevm-3.0 hosts are
+# updated with latest vdsm-bootstrap
+Requires: %{name}-cli = %{version}-%{release}
+
 %description
 The VDSM service is required by a Virtualization Manager to manage the
 Linux hosts. VDSM manages and monitors the host's storage, memory and
Comment 4 Alon Bar-Lev 2012-10-25 16:04:07 EDT
https://gerrit.eng.lab.tlv.redhat.com/#/c/2894/
Comment 5 Barak 2012-10-28 05:49:31 EDT
*** Bug 870315 has been marked as a duplicate of this bug. ***
Comment 11 errata-xmlrpc 2012-12-04 14:13:27 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-1508.html

Note You need to log in before you can comment on or make changes to this bug.