Bug 1658141
Summary: | OVS commands return warning messages with 2.10 | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Alfredo Moralejo <amoralej> |
Component: | dpdk | Assignee: | Timothy Redaelli <tredaelli> |
Status: | CLOSED WONTFIX | QA Contact: | Jean-Tsung Hsiao <jhsiao> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.6 | CC: | ailan, amoralej, apevec, chrisw, fhallal, fleitner, guillaume.pavese, hunter86_bg, jstransk, kecarter, ovs-qe, rhbz, rkhan, srevivo, tredaelli |
Target Milestone: | rc | Keywords: | Extras |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-03-15 07:32:24 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Alfredo Moralejo
2018-12-11 11:11:57 UTC
Root cause for this is in dpdk, not ovs. Apparently, dpdk is missing requirement in libibverbs. Could this be worked around by preinstalling libibverbs ? OVS 2.11 will be required once DPDK 18.11 is pushed to Extras, copying from IRC for the record:
> we need OVS trunk build from master when they'll merge the DPDK 18.11 patches (they are still approving those)
> > how do we track it?
> https://github.com/openvswitch/ovs/tree/dpdk-latest (not updated) or master + https://patchwork.ozlabs.org/patch/1011038/
more from IRC:
> the real problem is that OVS build system always links with DPDK also when it shouldn't (you have ovs-vsctl => libopenvswitch.so => libdpdk + all the pmds)
> ideally libdpdk + PMDs should only be linked to ovs-vswitchd
Seems to me that there there are two separate issues here: 1) ovs binaries are linked to dpdk libraries, so you're forced to have dpdk installed, even if you have no intention of using it. Could the dpdk libraries be "lazy loaded" somehow? 2) dpdk rpm is missing a dependency on ("requires") libibverbs. We don't want to force all customers to install libibverbs because only a very few of them will actually use Mellanox with DPDK. So there are two problems here: 1) The tools reporting linking error should be fixed as part of bz#1643478. 2) The daemon reporting linking error is harmless if not using DPDK Mellanox, and there is an effort in upstream to move the relevant dependencies to DPDK. When that is done, we won't need libibverbs. HTH, fbl Please see the previous comment and let me know what you think. fbl I'm ok with the solution proposed for linking error in tools. According to bz#1643478 it seems it's already fixed in RHEL, however we are still seeing this warnings for RDO, could this solution applied to the ovs build in RDO? I just ran into this same issue, while not specifically related to OvS, it was the same warning messages and resolution. Steps to Reproduce: 1. In a CentOS7 install "*-stein" 2. Install python-tripleoclient 3. run command: `su stack -` or any `sudo` command. Warning message: ``` net_mlx5: cannot load glue library: libibverbs.so.1: cannot open shared object file: No such file or directory net_mlx5: cannot initialize PMD due to missing run-time dependency on rdma-core libraries (libibverbs, libmlx5) PMD: net_mlx4: cannot load glue library: libibverbs.so.1: cannot open shared object file: No such file or directory PMD: net_mlx4: cannot initialize PMD due to missing run-time dependency on rdma-core libraries (libibverbs, libmlx4) net_mlx5: cannot load glue library: libibverbs.so.1: cannot open shared object file: No such file or directory net_mlx5: cannot initialize PMD due to missing run-time dependency on rdma-core libraries (libibverbs, libmlx5) PMD: net_mlx4: cannot load glue library: libibverbs.so.1: cannot open shared object file: No such file or directory PMD: net_mlx4: cannot initialize PMD due to missing run-time dependency on rdma-core libraries (libibverbs, libmlx4 ``` This issue came about after installing `python-tripleoclient` from stein with the following repos: ``` # yum repolist repo id repo name base/7/x86_64 CentOS-7 - Base 10,019 delorean-stein delorean-openstack-neutron-ac92596de9c064f7551323334e89367baf90838b 805+345 delorean-stein-build-deps dlrn-stein-build-deps 172+112 delorean-stein-testing dlrn-stein-testing 788+719 extras/7/x86_64 CentOS-7 - Extras 413 rdo-qemu-ev/x86_64 RDO CentOS-7 - QEMU EV 75 updates/7/x86_64 CentOS-7 - Updates ``` Current installed tripleo packages: ``` # rpm -qa | grep tripleo python2-tripleo-repos-0.0.1-0.20190520152004.8a48b48.el7.noarch openstack-tripleo-image-elements-10.4.1-0.20190426071146.7efbd4c.el7.noarch ansible-tripleo-ipsec-9.1.1-0.20190513182452.ffe104c.el7.noarch ansible-role-tripleo-modify-image-1.0.1-0.20190422120108.f1dfdc6.el7.noarch python2-tripleoclient-11.4.1-0.20190520164803.a55573f.el7.noarch puppet-tripleo-10.4.2-0.20190514170241.c25cd35.el7.noarch openstack-tripleo-validations-10.4.1-0.20190515192433.6ead160.el7.noarch python2-tripleoclient-heat-installer-11.4.1-0.20190520164803.a55573f.el7.noarch openstack-tripleo-common-containers-10.7.1-0.20190517182445.eeee6fb.el7.noarch openstack-tripleo-puppet-elements-10.3.1-0.20190426060644.a359301.el7.noarch python2-tripleo-common-10.7.1-0.20190517182445.eeee6fb.el7.noarch openstack-tripleo-common-10.7.1-0.20190517182445.eeee6fb.el7.noarch openstack-tripleo-heat-templates-10.5.1-0.20190520165934.0c31f04.el7.noarch ``` I can confirm that installing `libibverbs` resolved this specific issue. FYI the warnings breaking Puppet module parsing are breaking OpenStack upgrade. We can work around, but still it's questionable whether we should be doing the workaround, or just add the dependency. Being discussed here: https://review.opendev.org/#/c/643056/30/deployment/tripleo-packages/tripleo-packages-baremetal-puppet.yaml *** Bug 1753363 has been marked as a duplicate of this bug. *** After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days |