We are seeing an issue with 'import netifaces' after apt_install("python3_netifaces", fatal=True) is called from the charmhelpers.contrib.network.ip module during a charm install hook where we are importing functions from charmhelpers.contrib.openstack.utils.
unit-openstack-service-checks-0: 21:33:03 INFO unit.openstack-service-checks/0.juju-log Installing python3-netifaces with options: ['--option=Dpkg::Options::=--force-confold']
unit-openstack-service-checks-0: 21:33:03 DEBUG unit.openstack-service-checks/0.install Reading package lists...
unit-openstack-service-checks-0: 21:33:03 DEBUG unit.openstack-service-checks/0.install Building dependency tree...
unit-openstack-service-checks-0: 21:33:03 DEBUG unit.openstack-service-checks/0.install Reading state information...
unit-openstack-service-checks-0: 21:33:04 DEBUG unit.openstack-service-checks/0.install python3-netifaces is already the newest version (0.10.4-0.1build4).
unit-openstack-service-checks-0: 21:33:04 DEBUG unit.openstack-service-checks/0.install 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
unit-openstack-service-checks-0: 21:33:04 DEBUG worker.uniter.jujuc running hook tool "juju-log"
unit-openstack-service-checks-0: 21:33:04 ERROR unit.openstack-service-checks/0.juju-log Hook error:
Traceback (most recent call last):
File "/var/lib/juju/agents/unit-openstack-service-checks-0/.venv/lib/python3.6/site-packages/charmhelpers/contrib/network/ip.py", line 39, in <module>
import netifaces
ModuleNotFoundError: No module named 'netifaces'
You can see the full traceback from install hook on cs:~canonical-bootstack/openstack-service-checks-25 here: https://pastebin.ubuntu.com/p/bYhkbsjDbH/
This charm was previously compiled against charmhelpers==0.19.1 and worked fine, but now with charmhelpers==0.20.1, it appears apt_install functions are installing the package in the system locations, but the newly installed module is not available within the charm venv.
I am wondering if this commit may be related to the issues we are seeing:
https://github.com/juju/charm-helpers/commit/d2ea1b8d8c2fb5bc80b8ff2f7f81c82a02bd611b#diff-935a00f40074c3c59d617c88f71e42ef
You can see a working version of nearly identical code with charmhelpers 0.19.1 at cs:~canonical-bootstack/openstack-service-checks-24
The failing code is here:
https://github.com/juju/charm-helpers/blob/master/charmhelpers/contrib/network/ip.py#L46
It is imported from our layer here:
https://git.launchpad.net/charm-openstack-service-checks/tree/lib/lib_openstack_service_checks.py#n12
In our layer.yaml we set use_venv=true for layer-basic's options as a best practice, but it may be causing a containment issue that is no longer supported by charmhelpers.contrib.openstack.utils.
To reproduce:
juju install cs:~canonical-bootstack/openstack-service-checks-25
juju debug-log -i openstack-service-checks/0
The affected layer's repository is lp:charm-openstack-service-checks.
Actual issue is that layer-basic changed use_system_ packages= false 14 days ago:
https:/ /github. com/juju- solutions/ layer-basic/ commit/ df309d4071d44a9 b6a68c19b244ab7 2a69cee8ef
It seems inconsistent for layer-basic to auto-include charmhelpers in wheelhouse which uses techniques such as try: import x; except: apt_install(x); import x, and yet set include_ system_ packages = false.