Change of layer-basic include_system_packages to default==false causes charmhelpers import issues.

[Drew Freiberger]

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.

[Drew Freiberger (afreiberger)]

Actual issue is that layer-basic changed use_system_packages=false 14 days ago:

https://github.com/juju-solutions/layer-basic/commit/df309d4071d44a9b6a68c19b244ab72a69cee8ef

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.

[Drew Freiberger (afreiberger)]

This can be marked as Won't Fix.

It seems that this change is necessary for proper isolation of many charms surrounding series and version upgrades.

Charms using charmhelpers and venvs should take care to fill out the wheelhouse to include any imports done within the charmhelpers.contrib pieces they are using.

One such example is using charmhelpers.contrib.openstack modules would require using a wheelhouse that includes:

https://opendev.org/openstack/charm-layer-openstack/src/branch/master/wheelhouse.txt

[Stuart Bishop (stub)]

I think the dodgy charm-helpers imports are only in the (not supported by core + legacy code) contrib section.