Red Hat Bugzilla – Bug 1290096
[Upgrade] Dependency Resolution failed on "yum update" when upgrading RHEV 3.5->3.6
Last modified: 2016-02-21 23:41:28 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:
can you try with latest build? 3.6.1-4? adding sandro to see if there is a known issue
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.
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
(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.
(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).
(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.
(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.
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
(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.
(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.
Assigning Tahlia as the QA contact. Tahlia - could you take a look at the changes for this bug?
*** Bug 1305097 has been marked as a duplicate of this bug. ***
Documentation available at: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6-Beta/html-single/Upgrade_Guide/index.html#Upgrading_to_Red_Hat_Enterprise_Virtualization_Manager_3.6 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html-single/Installation_Guide/index.html#Upgrading_to_Red_Hat_Enterprise_Virtualization_Manager_3.5
Moving 'requires_doc_text' to '-' and clearing 'Doc Text' field. The instructions for upgrade have been updated in the documentation.