Comment 2 for bug 1965966

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.