Comment 8 for bug 1951462

There appears to be an issue with the fix for the ovn-central charm.

From its log:
2022-02-23 06:14:14 INFO juju unit_agent.go:276 Starting unit workers for "ovn-central/0"
...
2022-02-23 06:15:01 INFO unit.ovn-central/0.juju-log server.go:327 Invoking reactive handler: reactive/layer_openstack.py:15:default_install
2022-02-23 06:15:01 WARNING unit.ovn-central/0.juju-log server.go:327 Package openstack-release has no installation candidate.
2022-02-23 06:15:03 WARNING unit.ovn-central/0.juju-log server.go:327 Package horizon-common has no installation candidate.
2022-02-23 06:15:04 WARNING unit.ovn-central/0.juju-log server.go:327 Package openstack-release has no installation candidate.
2022-02-23 06:15:05 INFO unit.ovn-central/0.juju-log server.go:327 Installing ['ubuntu-cloud-keyring'] with options: ['--option=Dpkg::Options::=--force-confold']
2022-02-23 06:15:08 INFO unit.ovn-central/0.juju-log server.go:327 Installing ['ovn-central'] with options: ['--option=Dpkg::Options::=--force-confold']

As you can see the package install is attempted prior to adding UCA. I wonder if those are coming from the call to ``get_os_codename_package`` in charms.openstack.

Since the charm then does not retry even if it is listed in the Wallaby version of the charm class makes me wonder if the release selection process fails for the install hook so that the install hook is ran as one of the previous version classes. The UCA would still be set up correctly as that comes from charm config.

Since we have the same major version of OVN from Ussuri up until Xena we can't really override this behavior in the base class package codename map either.

*ponders on how to solve this problem*