Comment 1 for bug 1625859

The difference in the wheel name is due to a different compiler being used when compiling the wheel. Similar issues have been seen where the compute node where libvirt is installed has a different version installed to the repo server where the wheel is compiled. This may also be an issue where a suitable wheel is found on an extra index provided to the repo build process, but there's a mismatch in the packages installed between the compute host and the host where the wheel was compiled.

In order to determine the real root cause here, please can you supply the package list for the compute host and the repo server for both installs. Also please provide The following var values for both environments:

repo_build_pip_default_index
repo_build_pip_extra_index
repo_build_pip_extra_indexes

In Newton we added the repo_build_pip_no_binary variable in order to force the repo build process to always build packages in the list provided from source (never use wheels from any indexes). This covers the situation where an extra index is used but may not have the right binaries installed. If the environment has a homogenous build (same package versions on the repo container and the compute hosts) then this is perfectly good, and Newton already ensures that python-libvirt is set to always build from source.

If it is desired to allow the environment to have non-homogenous builds or inconsistent package versions between the repo server and the compute hosts then it may be better to implement a link from the nova venv into the system package for the python-libvirt system package in a similar way to how we do the ceph libs. I do think that it seems like a good operations practice to update the libvirt package at the same time as updating the nova venv though, so the linking should not be required.