Red Hat Bugzilla – Bug 1421533
[4.1 Beta] RHEL-H/RHV-H should have vdsm-client installed by default
Last modified: 2017-05-24 07:27:23 EDT
Description of problem: If vdsClient is deprecated in 4.1 then vdsm-client needs to be included by default. Latest node as of today is missing it: # which vdsm-client /usr/bin/which: no vdsm-client in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin) # rpm -qa | grep vdsm-client | wc -l 0 # rpm -qa | grep vdsm-4.19 vdsm-4.19.4-1.el7ev.x86_64 Version-Release number of selected component (if applicable): 4.1-20170202.0.el7_3
We don't track packages individually. It's likely that vdsm-cli is no longer in Requires: for some package which previously included it (my last awareness is that the vdsm sos plugin and ovirt-hosted-engine-setup needed it). I'll check the deptree of a couple of images tomorrow to see when the last time this was included was, and what change removed it, but we are not likely to explicitly include this in RHVH. Another package must require it.
Yes, I just noticed it's not in RHEL hosts too. Probably vdsm needs to require this package as a dependency. Do you want me to close this and open a BZ against it?
AFAIK, vdsm never required this. Just the vdsm sos plugin and ovirt-hosted-engine-setup. It was put on systems as part of host-deploy. Since it's deprecated and no longer needed, I'd guess that not shipping it by default is intentional. Whether to open a bug (or move this one) to included a deprecated package which is not a dependency of anything on RHVH is probably a PM decision.
(In reply to Ryan Barry from comment #3) > Since it's deprecated and no longer needed, I'd guess that not shipping it > by default is intentional. Hi Ryan, Deprecated? This is about vdsm-client which replaces (deprecates) vdsClient in 4.1 See https://www.mail-archive.com/users@ovirt.org/msg38714.html
Sorry, I had this confused with vdsm-cli. It's still likely that nothing requires this, which is why RHVH doesn't have it...
(In reply to Ryan Barry from comment #5) > Sorry, I had this confused with vdsm-cli. > > It's still likely that nothing requires this, which is why RHVH doesn't have > it... Right... So the solution is that some other package should required this right. So no need to open a separate bug for RHEL Hosts?
Let's wait to see what Moran says about inclusion.
Just to confirm, exact same thing on RHEL hosts after being added in RHV-M. # rpm -qa | grep vdsm vdsm-api-4.19.4-1.el7ev.noarch vdsm-cli-4.19.4-1.el7ev.noarch vdsm-python-4.19.4-1.el7ev.noarch vdsm-jsonrpc-4.19.4-1.el7ev.noarch vdsm-4.19.4-1.el7ev.x86_64 vdsm-hook-vmfex-dev-4.19.4-1.el7ev.noarch vdsm-xmlrpc-4.19.4-1.el7ev.noarch vdsm-yajsonrpc-4.19.4-1.el7ev.noarch # yum install vdsm-client Loaded plugins: product-id, search-disabled-repos, subscription-manager Resolving Dependencies --> Running transaction check ---> Package vdsm-client.noarch 0:4.19.4-1.el7ev will be installed --> Finished Dependency Resolution Installed: vdsm-client.noarch 0:4.19.4-1.el7ev Complete! # vdsm-client usage: vdsm-client [-h] [-a HOST] [-p PORT] [--unsecure] [--timeout TIMEOUT] [-f FILE] namespace method [method_args [method_args ...]] I think it should be included by default in both RHEL and RHV-H. Note: vdsClient is still included in both RHEL and RHV-H, but it's deprecated.
AFAIK vdsm-cli package (providing vdsClient) were never a direct dependency of vdsm, but it was installed on RHEL hosts during host-deploy (by default we install both packages vdsm and vdsm-cli). In 4.2 we will install vdsm-client package instead of vdsm-cli the same way. Unfortunately in 4.1 vdsm-client does not yet support all features of vdsClient, so we cannot say that it's a replacement (vdsm-client will replace vdsClient fully in 4.2).
(In reply to Martin Perina from comment #9) > AFAIK vdsm-cli package (providing vdsClient) were never a direct dependency > of vdsm, but it was installed on RHEL hosts during host-deploy (by default > we install both packages vdsm and vdsm-cli). In 4.2 we will install > vdsm-client package instead of vdsm-cli the same way. > Unfortunately in 4.1 vdsm-client does not yet support all features of > vdsClient, so we cannot say that it's a replacement (vdsm-client will > replace vdsClient fully in 4.2). Irit?
vdsm-client can provide replacement for most of vdsClient commands. We do have a few schema inconsistencies which we wish to resolve soon. Therefore, vdsClient isn't officially deprecated in 4.1. You can add vdsm-client but note there's a chance that a few commands will fail.
vdsClient is not maintained since 4.0 - the new storage verbs are available only in vdsm-client. I don't know about anything that may fail in vdsm-client, if there is some vdsm verb that does not work with it this is a bug.
Indeed the new vdsm-client is not required by anything. It is a debug tool, and on RHEL-H, it is installed by ovirt-host-deploy. I don't know why this does not happen for RHV-H. But as a useful light-weight debug tool, I think that RHV-H should ship it, one way or another.
In general, we only ship packages in RHV-H if they are dependencies of some other package. There are exceptions to this, but primarily platform tools for debugging (tcpdump, etc) or utilities to ensure we work everywhere (EFI tools, in general). vdsm-cli is required by ovirt-hosted-engine-ha. I would suggest (for the long term) some metapackage which only has requirements as a part of ovirt-host-deploy. We can add this to our list of requirements, and ovirt-host-deploy can install it. This way we keep in sync.
(In reply to Ryan Barry from comment #14) > In general, we only ship packages in RHV-H if they are dependencies of some > other package. > > There are exceptions to this, but primarily platform tools for debugging > (tcpdump, etc) or utilities to ensure we work everywhere (EFI tools, in > general). Sounds like it can fit vdsm-client. > > vdsm-cli is required by ovirt-hosted-engine-ha. Not for long - see bug 1101554. > > I would suggest (for the long term) some metapackage which only has > requirements as a part of ovirt-host-deploy. We can add this to our list of > requirements, and ovirt-host-deploy can install it. This way we keep in sync. You mean, to have e.g. 'ovirt-host-deps', that host-deploy installs, and that requires e.g. 'vdsm-client'? But some of the packages that host-deploy installs are optional. E.g. if engine or user set env key OpenStackEnv.NEUTRON_LINUXBRIDGE_ENABLE to True, host-deploy will install openstack-neutron-linuxbridge and vdsm-hook-openstacknet.
(In reply to Yedidyah Bar David from comment #15) > > Sounds like it can fit vdsm-client. It can, but... > You mean, to have e.g. 'ovirt-host-deps', that host-deploy installs, and > that requires e.g. 'vdsm-client'? But some of the packages that host-deploy > installs are optional. > > E.g. if engine or user set env key OpenStackEnv.NEUTRON_LINUXBRIDGE_ENABLE > to True, host-deploy will install openstack-neutron-linuxbridge and > vdsm-hook-openstacknet. Something like this, yes. There are some things which are unavoidable (optional deps if some key is set), but every package which host-deploy installs separately which is not tracked somewhere else (vdsm-client in this instance) tends to lead to a bug filed against RHV-H. Tracking non-optional packages in two different places (host-deploy and redhat-release-virtualization-host-content) seems to me to be inefficient and error-prone...
(In reply to Ryan Barry from comment #16) > There are some things which are unavoidable (optional deps if some key is > set), but every package which host-deploy installs separately which is not > tracked somewhere else (vdsm-client in this instance) tends to lead to a bug > filed against RHV-H. Tracking non-optional packages in two different places > (host-deploy and redhat-release-virtualization-host-content) seems to me to > be inefficient and error-prone... I see your point. Not sure what's the best solution though. We used to have -offline, which did more-or-less what you want, and then dropped it - see bug 1314790.
Moran, thoughts?
First of all sorry for the comment noise. In ovirt-hoste-deploy (for RHEL-H). This commit adds vdsm-client: commit 7ffe16eb85e68322c8a610fd7a285d6235ce5a81 packaging: Replace vdsm-cli with vdsm-client But: git branch --contains 7ffe16eb85e68322c8a610fd7a285d6235ce5a81 * master So don't we need it in the 1.6 branch as well? Looks like: 1) Somehow include vdsm-client in RHV-H? 2) cheery-pick that patch into 1.6 to cover RHEL-H?
Including vdsm-client in RHVH is easy enough, technically. The avoidance here is to keep the size of the image down for a non-required package. If host-deploy doesn't require it in 4.1 (and it's available on RHEL-H, of course), I'd suggest adding it to the list in https://bugzilla.redhat.com/show_bug.cgi?id=1405912 and closing this bug as a duplicate.
(In reply to Germano Veit Michel from comment #21) > First of all sorry for the comment noise. > > In ovirt-hoste-deploy (for RHEL-H). This commit adds vdsm-client: > > commit 7ffe16eb85e68322c8a610fd7a285d6235ce5a81 > packaging: Replace vdsm-cli with vdsm-client In 4.1 both vdsm-cli and vdsm-client are available and vdsm-cli is installed by ovirt-host-deploy. In master vdsm-cli has been dropped and ovirt-host-deploy will install vdsm-client. Simone, please check if vdsm-cli / vdsm-client is installed while deploying hosted-engine. If so, we need to add it to ovirt-hosted-engine-setup dependencies.
(In reply to Sandro Bonazzola from comment #23) > Simone, please check if vdsm-cli / vdsm-client is installed while deploying > hosted-engine. If so, we need to add it to ovirt-hosted-engine-setup > dependencies. On master vdsm-client is a dependency of ovirt-hosted-engine-ha although we don't really need it.
I've just made a clean and fresh deployment of hosted-engine on RHEVH4.1 and vdsm-client-4.19.7-1.el7ev.noarch is present: # rpm -qa | grep vdsm* vdsm-hook-openstacknet-4.19.7-1.el7ev.noarch vdsm-python-4.19.7-1.el7ev.noarch vdsm-api-4.19.7-1.el7ev.noarch vdsm-4.19.7-1.el7ev.x86_64 vdsm-yajsonrpc-4.19.7-1.el7ev.noarch vdsm-xmlrpc-4.19.7-1.el7ev.noarch vdsm-jsonrpc-4.19.7-1.el7ev.noarch vdsm-hook-vmfex-dev-4.19.7-1.el7ev.noarch vdsm-gluster-4.19.7-1.el7ev.noarch vdsm-hook-fcoe-4.19.7-1.el7ev.noarch vdsm-hook-vhostmd-4.19.7-1.el7ev.noarch vdsm-cli-4.19.7-1.el7ev.noarch vdsm-hook-ethtool-options-4.19.7-1.el7ev.noarch vdsm-client-4.19.7-1.el7ev.noarch ovirt-vmconsole-host-1.0.4-1.el7ev.noarch ovirt-engine-sdk-python-3.6.9.1-1.el7ev.noarch qemu-kvm-rhev-2.6.0-28.el7_3.6.x86_64 vdsm-4.19.7-1.el7ev.x86_64 ovirt-hosted-engine-ha-2.1.0.4-1.el7ev.noarch ovirt-imageio-common-1.0.0-0.el7ev.noarch ovirt-host-deploy-1.6.3-1.el7ev.noarch sanlock-3.4.0-1.el7.x86_64 ovirt-node-ng-nodectl-4.1.0-0.20170227.0.el7.noarch ovirt-imageio-daemon-1.0.0-0.el7ev.noarch ovirt-hosted-engine-setup-2.1.0.4-1.el7ev.noarch ovirt-vmconsole-1.0.4-1.el7ev.noarch libvirt-client-2.0.0-10.el7_3.5.x86_64 mom-0.5.9-1.el7ev.noarch ovirt-setup-lib-1.1.0-1.el7ev.noarch Linux version 3.10.0-514.6.1.el7.x86_64 (mockbuild@x86-030.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Sat Dec 10 11:15:38 EST 2016 Linux 3.10.0-514.6.1.el7.x86_64 #1 SMP Sat Dec 10 11:15:38 EST 2016 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux release 7.3 # which vdsm-client /usr/bin/vdsm-client # rpm -qa | grep vdsm-client | wc -l 1
ovirt-hosted-engine-ha-2.1.0.4 requires it
Moving to verified forth to comment #25.
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. https://access.redhat.com/errata/RHBA-2017:1291