Install hook fails when charm's openstack-origin is passed a non-distro repository without OS codename in it's name

[Ksawery Dziekoński]

When a non-distro `openstack-origin` repository does not contain an Openstack codename (for example, is `ppa:ksdziekonski/os-playground`), which is apparently an in-charm convention used to determine Keystone API version to roll out, it leads to the installation hook failing ambiguously, due to `get_os_codename_install_source()` implicitly returning `None` after falling through all of the function's conditions.

Traceback (most recent call last):
  File "/var/lib/juju/agents/unit-keystone-0/charm/charmhelpers/core/strutils.py", line 95, in __init__
    self.index = self._list.index(item)
ValueError: tuple.index(x): x not in tuple

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/var/lib/juju/agents/unit-keystone-0/charm/hooks/install.real", line 937, in <module>
    main()
  File "/var/lib/juju/agents/unit-keystone-0/charm/hooks/install.real", line 933, in main
    assess_status(CONFIGS)
  File "/var/lib/juju/agents/unit-keystone-0/charm/hooks/keystone_utils.py", line 2455, in assess_status
    assess_status_func(configs)()
  File "/var/lib/juju/agents/unit-keystone-0/charm/charmhelpers/contrib/openstack/utils.py", line 1787, in _assess_status_func
    state, message = _determine_os_workload_status(*args, **kwargs)
  File "/var/lib/juju/agents/unit-keystone-0/charm/charmhelpers/contrib/openstack/utils.py", line 1033, in _determine_os_workload_status
    state, message = _ows_check_generic_interfaces(
  File "/var/lib/juju/agents/unit-keystone-0/charm/charmhelpers/contrib/openstack/utils.py", line 1122, in _ows_check_generic_interfaces
    incomplete_rel_data = incomplete_relation_data(configs,
  File "/var/lib/juju/agents/unit-keystone-0/charm/charmhelpers/contrib/openstack/utils.py", line 1406, in incomplete_relation_data
    complete_ctxts = configs.complete_contexts()
  File "/var/lib/juju/agents/unit-keystone-0/charm/charmhelpers/contrib/openstack/templating.py", line 350, in complete_contexts
    [interfaces.extend(i.complete_contexts())
  File "/var/lib/juju/agents/unit-keystone-0/charm/charmhelpers/contrib/openstack/templating.py", line 350, in <listcomp>
    [interfaces.extend(i.complete_contexts())
  File "/var/lib/juju/agents/unit-keystone-0/charm/charmhelpers/contrib/openstack/templating.py", line 127, in complete_contexts
    self.context()
  File "/var/lib/juju/agents/unit-keystone-0/charm/charmhelpers/contrib/openstack/templating.py", line 112, in context
    _ctxt = context()
  File "/var/lib/juju/agents/unit-keystone-0/charm/hooks/keystone_context.py", line 183, in __call__
    ctxt['api_version'] = get_api_version()
  File "/var/lib/juju/agents/unit-keystone-0/charm/hooks/keystone_utils.py", line 1498, in get_api_version
    cmp_release = CompareOpenStackReleases(
  File "/var/lib/juju/agents/unit-keystone-0/charm/charmhelpers/core/strutils.py", line 97, in __init__
    raise KeyError("Item '{}' is not in list '{}'"
KeyError: "Item 'None' is not in list '('diablo', 'essex', 'folsom', 'grizzly', 'havana', 'icehouse', 'juno', 'kilo', 'liberty', 'mitaka', 'newton', 'ocata', 'pike', 'queens', 'rocky', 'stein', 'train', 'ussuri', 'victoria', 'wallaby', 'xena', 'yoga')'"
juju.worker.uniter.operation hook "install" (via explicit, bespoke hook script) failed: exit status 1

[Corey Bryant (corey.bryant)]

Thanks Xav. Can you describe your plans for fixing this?

[Ksawery Dziekoński (ksdziekonski)]

Main two ways of fixing this would be:

a) leveraging other existing functions to complement information from `get_os_codename_install_source(src)` where it's being called, for example with `os_release(pkg)`, which also infers codename information from the package manager, then from distribution's base - in the case of a custom repository, `openstack_upgrade_available()`, as it is as of this writing, might not be able to fulfill it's function, but the changes are small enough to be understood at a glance, while being a functional no-op for existing execution flows

b) refractoring a couple of places in the charm's codebase, allowing `get_os_codename_install_source()`'s inability to infer the Openstack's release codename to block deployment progress - probably saner from a UX standpoint, as it doesn't derive potentially non-obvious defaults, but a lot more invasive and prone to error in old production code end users may have grown accustomed to

Since I'm leaning towards considering this a bug and not a feature request, option A feels safer and more suitable in the immediate.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/charm-keystone/+/835087