Description of problem: The host-deploy (install) process fails when adding a RHEL7 host. This is because the names of vdsm packages have changed and the current code does not understand how to find the packages by their new names. The solution is to teach host-deploy to prefer the vdsm packages that are built on python3 and fall back to the python2 packages if necessary. Version-Release number of selected component (if applicable): ovirt-host-deploy-1.2.0-0.1.beta.fc19.noarch How reproducible: Always Steps to Reproduce: 1. Install ovirt-engine normally 2. Try to add a RHEL7 host Actual results: Traceback (most recent call last): File "/tmp/ovirt-4byBFcz9iL/pythonlib/otopi/context.py", line 142, in _executeMethod method['method']() File "/tmp/ovirt-4byBFcz9iL/otopi-plugins/ovirt-host-deploy/vdsm/packages.py", line 110, in _packages self.packager.installUpdate(('vdsm', 'vdsm-cli')) File "/tmp/ovirt-4byBFcz9iL/pythonlib/otopi/packager.py", line 139, in installUpdate ignoreErrors=ignoreErrors, File "/tmp/ovirt-4byBFcz9iL/otopi-plugins/otopi/packagers/yumpackager.py", line 295, in install ignoreErrors=ignoreErrors File "/tmp/ovirt-4byBFcz9iL/pythonlib/otopi/miniyum.py", line 782, in install return self._queue('install', self._yb.install, packages, **kwargs) File "/tmp/ovirt-4byBFcz9iL/pythonlib/otopi/miniyum.py", line 449, in _queue call(name=package) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 4788, in install raise Errors.InstallError, _('No package(s) available to install') InstallError: No package(s) available to install Expected results: The host should install successfully Additional info:
I do not understand... vdsm should be in one name eventually we will support one set of packages. Regardless, package renames should also contains the "Provides" statement within their spec for the previous name to allow it being pulled.
(In reply to Alon Bar-Lev from comment #1) > I do not understand... vdsm should be in one name eventually we will support > one set of packages. > > Regardless, package renames should also contains the "Provides" statement > within their spec for the previous name to allow it being pulled. Indeed looks vdsm spec. Moving to me.
danken - will "vdsm3 provides vdsm" work when we later have vdsm as well (for 4.0). i.e., how would yum know to use the new vdsm - if vdsm obsoletes vdsm3, which provides vdsm, sounds like a loop to me?
Valentina, maybe you can help us here, too? Regarding the question of comment3.
The way obsoletes work is this: The installed packages matching the Obsoletes: are replaced by the packages containing the Obsoletes. For single packages this can be thought of as update while changing the package name. As you plan to obsolete vdsm3 by vdsm I really don't see any loops here. Note that obsoletes do work on package names only. This is done explicitly to allow such loops. The new package obsoletes the old one and providing the old pkg name. In general rpm (and yum) ignores self conflicts. To be able to reintroduce the old package name later on (vdsm3 in your case) the obsolete should be versioned. Typically like Obsoletes: foo <= 1.2.3-2. This way the obsolete does not affect newer versions of foo and foo can be reintroduces later on (probably by obsoleting the old new package name).
(In reply to Florian Festi from comment #5) > The way obsoletes work is this: > > The installed packages matching the Obsoletes: are replaced by the packages > containing the Obsoletes. > For single packages this can be thought of as update while changing the > package name. As you plan to obsolete vdsm3 by vdsm I really don't see any > loops here. Note that obsoletes do work on package names only. This is done > explicitly to allow such loops. The new package obsoletes the old one and > providing the old pkg name. > > In general rpm (and yum) ignores self conflicts. > > To be able to reintroduce the old package name later on (vdsm3 in your case) > the obsolete should be versioned. Typically like Obsoletes: foo <= 1.2.3-2. > This way the obsolete does not affect newer versions of foo and foo can be > reintroduces later on (probably by obsoleting the old new package name). Agreed, I would do for example: vdsm3 - let's say current version is (4.14.2-0): ================================================= Provides vdsm = %{version}-%{release} Obsoletes: vdsm < 4.14.2-0 then new vsdm which version might be in the future like: 4.50.0-0 ================================================================== Provides vdsm = %{version}-%{release} Obsoletes: vdsm < 4.50.0-0
I am reopening this bug because vdsm3-cli does not provide vdsm-cli therefore host-deploy fails
Every subpackage should do the same, not just cli.
I tried to to add rhel7 host to 3.4 engine. The host deployment did not log any errors, and i have the vdsm pacakges installed: vdsm3-xmlrpc-4.14.2-2.el7.noarch vdsm3-python-4.14.2-2.el7.x86_64 vdsm3-4.14.2-2.el7.x86_64 vdsm3-python-zombiereaper-4.14.2-2.el7.noarch vdsm3-cli-4.14.2-2.el7.noarch but the host didn't go up. snippet from engine.log [attached]: 2014-03-18 16:06:46,413 ERROR [org.ovirt.engine.core.bll.InstallVdsCommand] (org.ovirt.thread.pool-4-thread-32) [3adc0f9d] Host installation failed for host 90c686f2-533d-43c8-a9c6-7f18f3a1 5e06, cinteg03.ci.lab.tlv.redhat.com.: org.ovirt.engine.core.bll.InstallVdsCommand$VdsInstallException: Network error during communication with the host at org.ovirt.engine.core.bll.InstallVdsCommand.configureManagementNetwork(InstallVdsCommand.java:313) [bll.jar:] at org.ovirt.engine.core.bll.InstallVdsCommand.installHost(InstallVdsCommand.java:238) [bll.jar:] at org.ovirt.engine.core.bll.InstallVdsCommand.executeCommand(InstallVdsCommand.java:140) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1123) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1208) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1884) [bll.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:174) [utils.jar:] at org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:116) [utils.jar:] at org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1228) [bll.jar:] at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:351) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:413) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:392) [bll.jar:] at org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:634) [bll.jar: Is this related? should i reassign this bug? or verify it and open a new BZ regarding the host doesn't go UP (it is because there is no rhevm bridge on any network interface)
Created attachment 875959 [details] enginelog rhevm-3.4.0-0.5.master.el6ev.noarch ovirt-host-deploy-1.1.3-1.el6ev.noarch
(In reply to Tareq Alayan from comment #16) > Created attachment 875959 [details] > enginelog > > rhevm-3.4.0-0.5.master.el6ev.noarch > ovirt-host-deploy-1.1.3-1.el6ev.noarch this bug is resolved now, host-deploy finishes successfully. please open a new one for vdsm communication error. I also had this in my environment, although vdsm is started, it is not communicating. I guess vdsm logs are required for this one.
Agreed with Alon, this bug is about deploy. However, the other issue vdsm not starting and host is not up, please see https://bugzilla.redhat.com/show_bug.cgi?id=1076889.
Thanks verified.
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/RHBA-2014-0504.html