I'm not clear on how to trigger the set of installed packages that leads to this bug, but in any case, I ran into an issue where neutron-dhcp-agent would refuse to work. Logs looked like this:
Apr 22 14:51:48 juju-df624b-4-lxd-10 neutron-dhcp-agent[1999891]: 2019-04-22 14:51:48.176 2000527 CRITICAL privsep [-] Unhandled error: ImportError: No module named neutron.privileged
Apr 22 14:51:48 juju-df624b-4-lxd-10 neutron-dhcp-agent[1999891]: 2019-04-22 14:51:48.176 2000527 ERROR privsep Traceback (most recent call last):
Apr 22 14:51:48 juju-df624b-4-lxd-10 neutron-dhcp-agent[1999891]: 2019-04-22 14:51:48.176 2000527 ERROR privsep File "/usr/bin/privsep-helper", line 10, in <module>
Apr 22 14:51:48 juju-df624b-4-lxd-10 neutron-dhcp-agent[1999891]: 2019-04-22 14:51:48.176 2000527 ERROR privsep sys.exit(helper_main())
Apr 22 14:51:48 juju-df624b-4-lxd-10 neutron-dhcp-agent[1999891]: 2019-04-22 14:51:48.176 2000527 ERROR privsep File "/usr/lib/python2.7/dist-packages/oslo_privsep/daemon.py", line 480, in helper_main
Apr 22 14:51:48 juju-df624b-4-lxd-10 neutron-dhcp-agent[1999891]: 2019-04-22 14:51:48.176 2000527 ERROR privsep context = importutils.import_class(cfg.CONF.privsep_context)
Apr 22 14:51:48 juju-df624b-4-lxd-10 neutron-dhcp-agent[1999891]: 2019-04-22 14:51:48.176 2000527 ERROR privsep File "/usr/lib/python2.7/dist-packages/oslo_utils/importutils.py", line 30, in import_class
Apr 22 14:51:48 juju-df624b-4-lxd-10 neutron-dhcp-agent[1999891]: 2019-04-22 14:51:48.176 2000527 ERROR privsep __import__(mod_str)
Apr 22 14:51:48 juju-df624b-4-lxd-10 neutron-dhcp-agent[1999891]: 2019-04-22 14:51:48.176 2000527 ERROR privsep ImportError: No module named neutron.privileged
Looking at the neutron-dhcp-agent process, it was invoked using python3.6, whereas the traceback shows errors with python2.7.
With python3-neutron installed and an older python-oslo.privsep and newner python3-oslo.privsep set of packages, the wrapper defaults to the 2.7 version, which stops the agent from working. Again, I'm not sure what the process was that led up to the new python3-oslo.privsep being installed, but the cloud has been upgraded through various releases, so at some point neutron switched over to python3-neutron.
The issue appears to be the upgrade did not run update-alternatives, which results in the following:
sudo update-alternatives --config privsep-helper
There are 2 choices for the alternative privsep-helper (providing /usr/bin/privsep-helper).
Selection Path Priority Status
------------------------------------------------------------
* 0 /usr/bin/python2-privsep-helper 300 auto mode
1 /usr/bin/python2-privsep-helper 300 manual mode
2 /usr/bin/python3-privsep-helper 200 manual mode
Switching the privsep-helper to python3-privsep-helper gets the neutron-dhcp-agent running again.
Switching to python3 in cosmic or bionic/rocky is 100% manual in terms of switching alternatives OR ensuring that the python-* modules are purged or not installed in the first place.
For stein, the default is python3 so auto mode should do the right things in terms of picking binaries, and for train python2 is being completely dropped.
Which release are you having issues with?