This makes the grep match in check_python3_support_for_package_local
the same as check_python3_support_for_package_remote.
Change I0349de2026c49279ba7f262d5e86d37018d66326 in grenade started
setting the PYTHON3_VERSION variable, and then we recently started
using bionic nodes everywhere which means we're running python 3.6.
The etcd3gw package has a python 3 and 3.5 classifier, but not 3.6:
https://pypi.org/project/etcd3gw/
The pip_install function code that is dealing with installing py3
packages is hitting a problem installing etcd3gw if the package is
local because of the more restrictive grep in the
check_python3_support_for_package_local function, and since
PYTHON3_VERSION=3.6 now, we don't install from py3 and install
etcd3gw on python 2.7 which makes services like cinder-volume and
cinder-backup, which use etcd3gw, fail when they are running under
python 3 (they get module import errors).
This simply removes the $ restriction on the grep. Looking at the
change that added those local/remote functions:
I243ea4b76f0d5ef57a03b5b0798a05468ee6de9b
There is no explanation for the difference, it just said:
Also, since not many packages are classified correctly, fallback
to looking for just "Programming Language :: Python :: 3" and
log a message for the package to highlight the problem.
So that's what this change does.
Note that alternatives would be:
1. Update the etcd3gw package to add the 3.6 classifier and do
a release (this should probably happen anyway).
2. Add etcd3gw to ENABLED_PYTHON3_PACKAGES but that would be a
short-term hack workaround.
Change-Id: Icd3768870ba0f1659bb2e6f002043d975047b73e
Closes-Bug: #1820892
ddb6179b04