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 (. versioning has no relevance):
https://github.com/juju/charm-helpers/blob/v0.18.3/charmhelpers/contrib/openstack/utils.py#L476-L480
A sample unfiltered trace (search for "KeyError: '4.14'"):
https://gist.github.com/dshcherb/4789ea8c16db45617b68bdd6bb59e656

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