Bug 1290096 - [Upgrade] Dependency Resolution failed on "yum update" when upgrading RHEV 3.5->3.6
[Upgrade] Dependency Resolution failed on "yum update" when upgrading RHEV 3....
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: Documentation (Show other bugs)
3.6.1
Unspecified Unspecified
high Severity high
: ovirt-3.6.2
: ---
Assigned To: Julie
Tahlia Richardson
: Reopened
: 1305097 (view as bug list)
Depends On:
Blocks: RHEV3.6Upgrade
  Show dependency treegraph
 
Reported: 2015-12-09 11:26 EST by Gil Klein
Modified: 2016-02-21 23:41 EST (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-09 01:23:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Docs
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gil Klein 2015-12-09 11:26:48 EST
Description of problem:

Dependency Resolution failed on "yum update" when upgrading 3.5->3.6


Version-Release number of selected component (if applicable):
From: rhevm-3.5.6.2-0.1.el6ev.noarch
To: rhevm-3.6.1.1-0.1.el6.noarch


How reproducible:
Always 


Steps to Reproduce:
1. Install RHEV 3.5.6
2. Run engine-setup to deploy the engine
3. Add RHEV 3.6 repos
4. Run "yum update"

Actual results:
--> Finished Dependency Resolution
Error: Package: rhevm-backend-3.5.6.2-0.1.el6ev.noarch (@qa-latest)
           Requires: vdsm-jsonrpc-java < 1.1.0
           Removing: vdsm-jsonrpc-java-1.0.15-1.el6ev.noarch (@qa-latest)
               vdsm-jsonrpc-java = 1.0.15-1.el6ev
           Updated By: vdsm-jsonrpc-java-1.1.5-1.el6ev.noarch (rhev-3.6.1-2)
               vdsm-jsonrpc-java = 1.1.5-1.el6ev
Error: Package: rhevm-reports-3.5.5-2.el6ev.noarch (@qa-latest)
           Requires: jasperreports-server-pro < 5.6.0
           Removing: jasperreports-server-pro-5.5.0-10.el6ev.noarch (@qa-latest)
               jasperreports-server-pro = 5.5.0-10.el6ev
           Updated By: jasperreports-server-pro-6.0.1-1.el6ev.noarch (rhev-3.6.1-2)
               jasperreports-server-pro = 6.0.1-1.el6ev
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest



Expected results:
yum update should be able to resolve dependencies and upgrade all pacakges


Additional info:
Comment 5 Eyal Edri 2015-12-14 03:23:46 EST
can you try with latest build? 3.6.1-4?
adding sandro to see if there is a known issue
Comment 6 Eyal Edri 2015-12-14 03:26:41 EST
also, i don't think "yum update" is the right way to upgrade.
you should run engine-setup, or only yum update rhevm-setup and then engine-setup.
Comment 7 Sandro Bonazzola 2015-12-14 03:41:15 EST
yum correctly protected the system by being broken by an update.
rhevm-reports-3.5.5-2.el6ev.noarch  and rhevm-backend-3.5.6.2-0.1.el6ev.noarch are version locked because for properly updating them you should run engine-setup.

vdsm-jsonrpc-java = 1.1.5-1.el6ev is available as an update but if yum updates it, it will break rhevm-backend-3.5.6.2-0.1.el6ev.noarch so the requirement in rhevm-backend-3.5.6.2 is correctly requiring vdsm-jsonrpc-java < 1.1.0.

jasperreports-server-pro = 6.0.1-1.el6ev is available as an update but if yum updates it, it will break rhevm-reports-3.5.5-2.el6ev.noarch so  the requirement in rhevm-reports-3.5.5 is correctly requiring jasperreports-server-pro < 5.6.0.

In order to perform the update you can either:

yum update --skip-broken and then run engine-setup
or:

yum update "rhevm-setup*"
engine-setup
yum update
Comment 10 Nikolai Sednev 2015-12-20 03:15:42 EST
(In reply to Eyal Edri from comment #6)
> also, i don't think "yum update" is the right way to upgrade.
> you should run engine-setup, or only yum update rhevm-setup and then
> engine-setup.

Following steps 2->5 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Installation_Guide/sect-Upgrading_to_Red_Hat_Enterprise_Virtualization_3.5.html:
# yum update
# yum update rhevm-setup
# engine-setup

I've also seen this dependency issue, but it might be WA by changing the upgrade work flow as follows:
# yum update rhevm-setup
# yum update
# engine-setup

From the perspective of general OS updates, dependency on RHEL component yet looks problematic.
Comment 11 Yedidyah Bar David 2015-12-20 03:40:11 EST
(In reply to Nikolai Sednev from comment #10)
> From the perspective of general OS updates, dependency on RHEL component yet
> looks problematic.

I'd like to clarify.

The correct upgrade procedure is:

1. Have an existing system with whatever version available in your z-stream.
2. Run yum update if you want. 
3. Add repos of next version.
4. yum update the setup packages.
5. engine-setup
6. yum update

In particular:
A. We do not (try to) support running 'yum update' between (3.) and (4.).
B. Meaning, if you decide you want to upgrade, you have to do that in one shot. Not add repos and then do other stuff.

If you find the above problematic, please suggest another flow (which still accepts the current use of versionlock, which is a different issue). In particular, there might be some yum option/plugin/whatever that will allow running 'yum update' and still keep all deps/conflicts satisfied, *including* versionlock. Never researched this, and not sure what hooks are available to yum plugins - if versionlock is able to affect also the list of packages to be upgraded, both before and after dependency resolution, and not merely prevent an update once the list is computed, it might be possible. You might open this as a bug/rfe on yum (or dnf).
Comment 12 Nikolai Sednev 2015-12-20 06:08:22 EST
(In reply to Yedidyah Bar David from comment #11)
> (In reply to Nikolai Sednev from comment #10)
> > From the perspective of general OS updates, dependency on RHEL component yet
> > looks problematic.
> 
> I'd like to clarify.
> 
> The correct upgrade procedure is:
> 
> 1. Have an existing system with whatever version available in your z-stream.
> 2. Run yum update if you want. 
> 3. Add repos of next version.
> 4. yum update the setup packages.
> 5. engine-setup
> 6. yum update
> 
> In particular:
> A. We do not (try to) support running 'yum update' between (3.) and (4.).
> B. Meaning, if you decide you want to upgrade, you have to do that in one
> shot. Not add repos and then do other stuff.
> 
> If you find the above problematic, please suggest another flow (which still
> accepts the current use of versionlock, which is a different issue). In
> particular, there might be some yum option/plugin/whatever that will allow
> running 'yum update' and still keep all deps/conflicts satisfied,
> *including* versionlock. Never researched this, and not sure what hooks are
> available to yum plugins - if versionlock is able to affect also the list of
> packages to be upgraded, both before and after dependency resolution, and
> not merely prevent an update once the list is computed, it might be
> possible. You might open this as a bug/rfe on yum (or dnf).

It's perfectly fine as long as we're aligned to the documented upgrade scenario, which currently not quite correct.
The only improvement which I can see here is to make an engine upgrade procedure available via WEBUI of the engine, just like it's possible to upgrade FW version for network devices, once it's available from local source or online, it will ensure correct upgrade procedure as it'll be executed by in background automatically, once done, engine will come back online.
Comment 13 Yedidyah Bar David 2015-12-20 06:24:27 EST
(In reply to Nikolai Sednev from comment #12)
> 
> It's perfectly fine as long as we're aligned to the documented upgrade
> scenario, which currently not quite correct.

That's iiuc the current scope of current bug.

> The only improvement which I can see here is to make an engine upgrade
> procedure available via WEBUI of the engine, just like it's possible to
> upgrade FW version for network devices, once it's available from local
> source or online, it will ensure correct upgrade procedure as it'll be
> executed by in background automatically, once done, engine will come back
> online.

Not sure this aligns well with the current architecture, as engine-setup runs as root (and in many cases needs that) while the engine runs as a regular user.

See also bug 951799.
Comment 14 Julie 2015-12-22 23:54:39 EST
Hi Didi,
   So my understanding is that the upgrade workflow should be:

1. Have an existing system with whatever version available in your z-stream.
2. Add repos of next version.
3. yum update the setup packages.
4. engine-setup
5. remove repos of the old version
6. yum update

Please confirm if this is correct and applies to all upgrade procedures from 3.1 to 3.6 Beta.

Kind regards,
Julie
Comment 15 Nikolai Sednev 2015-12-23 02:09:50 EST
(In reply to Julie from comment #14)
> Hi Didi,
>    So my understanding is that the upgrade workflow should be:
> 
> 1. Have an existing system with whatever version available in your z-stream.
> 2. Add repos of next version.
> 3. yum update the setup packages.
> 4. engine-setup
> 5. remove repos of the old version
> 6. yum update
> 
> Please confirm if this is correct and applies to all upgrade procedures from
> 3.1 to 3.6 Beta.
> 
> Kind regards,
> Julie

This work flow was correct and successful for me while I performed RHEVM3.4(3.4.5-0.3)->RHEVM3.5(3.5.6.2-0.1)->RHEVM3.5(3.5.7-0.1)->RHEVM3.6(3.6.1.3-0.1).

The same work flow should work also for 3.1.
Comment 16 Yedidyah Bar David 2015-12-23 03:52:48 EST
(In reply to Julie from comment #14)
> Hi Didi,
>    So my understanding is that the upgrade workflow should be:
> 
> 1. Have an existing system with whatever version available in your z-stream.
> 2. Add repos of next version.
> 3. yum update the setup packages.
> 4. engine-setup
> 5. remove repos of the old version
> 6. yum update
> 
> Please confirm if this is correct and applies to all upgrade procedures from
> 3.1 to 3.6 Beta.

Yes, afaik.

I don't know well <=3.2.

There were significant changes to implementation in 3.3 (for the engine) and 3.4 (for dwh/reports). Otherwise the principle was kept as above.
Comment 18 Andrew Dahms 2016-01-03 20:16:40 EST
Assigning Tahlia as the QA contact.

Tahlia - could you take a look at the changes for this bug?
Comment 20 Oved Ourfali 2016-02-07 02:47:31 EST
*** Bug 1305097 has been marked as a duplicate of this bug. ***
Comment 22 Lucy Bopf 2016-02-21 23:41:28 EST
Moving 'requires_doc_text' to '-' and clearing 'Doc Text' field. The instructions for upgrade have been updated in the documentation.

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