Default release selector function does not make use of local domain knowledge

[Frode Nordahl]

A charm implemented with the charms.openstack library has the power to define a map of package to (version, OpenStack release) tuples which is used in parts of the charms.openstack library (for determination of whether an OpenStack upgrade is available for example).

The default release selector function does however _NOT_ use this information.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/708566

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/708566
Committed: https://git.openstack.org/cgit/openstack/charms.openstack/commit/?id=76ba2b9c44bada3154573f1ed450bee20565e99f
Submitter: Zuul
Branch: master

commit 76ba2b9c44bada3154573f1ed450bee20565e99f
Author: Frode Nordahl <email address hidden>
Date: Wed Feb 19 07:45:32 2020 +0100

    Use charm codenames for select release when provided

    A charm class can provide a dictionary that maps package
    versions to OpenStack releases. This dictionary is
    consulted when determining if a OpenStack upgrade is available.

    However, when determining release for selection of charm class
    the map is not consulted. This patch teaches the default select
    release handler how to do so.

    Pass on source configuration key as specified by charm class
    to charm-helpers where appropriate.

    Change-Id: If7f35e7d00533599c3800aa4a22c51861017969e
    Closes-Bug: #1863774

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.opendev.org/711596

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/711596
Committed: https://git.openstack.org/cgit/openstack/charms.openstack/commit/?id=5deeb8afb8d34ce6ddf338dfe21c920e7f62b94d
Submitter: Zuul
Branch: master

commit 5deeb8afb8d34ce6ddf338dfe21c920e7f62b94d
Author: Frode Nordahl <email address hidden>
Date: Fri Mar 6 10:03:57 2020 +0100

    release select: Handle None return from get_os_codename_package

    Change If7f35e7d00533599c3800aa4a22c51861017969e introduced a bug
    that roots in the assumption that the ``get_os_codename_package``
    function when called with ``fatal=True`` would raise an exception
    in the event package or major version was not present in the map
    provided to the function.

    Instead of changing the API of ``get_os_codename_package`` method
    we detect a ``None`` return in the default select handler.

    Change-Id: Icad1811d1f183da25872b81192b69284373fbefb
    Related-Bug: #1863774