Comment 3 for bug 1744886

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to charms.openstack (master)

Reviewed: https://review.openstack.org/536776
Committed: https://git.openstack.org/cgit/openstack/charms.openstack/commit/?id=6cfcb8b79877499f177e2bbf076f7f50cdc228af
Submitter: Zuul
Branch: master

commit 6cfcb8b79877499f177e2bbf076f7f50cdc228af
Author: Liam Young <email address hidden>
Date: Tue Jan 23 10:47:44 2018 +0000

    Render SSL config when resolve_address changes

    When supplying certs and keys directly to the charm then
    get_certs_and_keys is hardcoded to return a cn of None. However,
    when the certs are written to disk configure_cert checks if the cn
    is None and if it is sets the cn to
    os_ip.resolve_address(endpoint_type=os_ip.INTERNAL). This causes an
    issue because generating the certs and keys is gated on a change to
    the return of get_certs_and_keys which always sets cn to None,
    however when the charm is clustered os_ip.resolve_address will
    return the vip which should change the cn. This means that if the
    charm transitions from un-clustered to clustered ssl certs will not
    be reconfigured if they have been configured already despite the cn
    having changed.

    This patch changes the default of cn in get_certs_and_keys to be
    os_ip.resolve_address(endpoint_type=os_ip.INTERNAL). Although this
    is a change in behaviour I believe that no charms are calling
    get_certs_and_keys directly and the risk is very low.

    Change-Id: I598bc822afa535fc865a333033069cfe05d7259d
    Closes-Bug: #1744886