juju
os_release incorrectly detects openstack version by keystone-middleware package if openstack-origin is not present
For most of the OpenStack charms openstack-origin is present, however, subordinates may not always have this option because they rely on a primary charm's versions (e.g. keystone-ldap charm) given that they share a machine and debian packages (not sure how snaps will be handled in this case).
https://github.com/juju/charm-helpers/blob/v0.18.3/charmhelpers/contrib/openstack/utils.py#L514-L535
charms.openstack has default_select_release which uses python-keystonemiddleware as a package to be passed to os_release unconditionally: https://github.com/juju/charm-helpers/blob/v0.18.3/charmhelpers/contrib/openstack/utils.py#L532 https://github.com/openstack/charms.openstack/blob/389d928ba50915560b2140e022a663035fa86a4b/charms_openstack/charm/defaults.py#L82-L101
There is no definition for python-keystonemiddleware in PACKAGE_CODENAMES https://github.com/juju/charm-helpers/blob/v0.18.3/charmhelpers/contrib/openstack/utils.py#L197
which is why OPENSTACK_CODENAMES are used:
https://github.com/juju/charm-helpers/blob/v0.18.3/charmhelpers/contrib/openstack/utils.py#L466-L480 https://github.com/juju/charm-helpers/blob/v0.18.3/charmhelpers/contrib/openstack/utils.py#L147-L162
For python-keystonemiddleware this results in KeyError because it uses different versions from the ones in OPENSTACK_CODENAMES (
And, finally, _os_rel == base == 'essex' is returned from os_release: https://github.com/juju/charm-helpers/blob/v0.18.3/charmhelpers/contrib/openstack/utils.py#L534
This is quite problematic as default_select_release release selector from charms.openstack doesn't take release_pkg into account even if it is present in a charm class definition (because a handler is not aware of the charm class in use): https://bugs.launchpad.net/charms.openstack/+bug/1741628
