leader-change does not trigger relation settings consistency check

[Edward Hope-Morley]

Currently the keystone charm, when deployed in HA, will apply settings to remote units from the leader only. While this is in itself inadequate from a design perspective and there are ongoing discussions about how best to provide cross-peer consistency, the charm does currently use events like config-changed to ensure consistency from the leader. Now, the problem here lies in the fact that the one event that does not trigger a consistency check is leader-elected which would fire when the leader switches. So to resolve this issue while maintain the current consistency design we simple need to add the relation sweep to this hook handler.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/509634

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/509634
Committed: https://git.openstack.org/cgit/openstack/charm-keystone/commit/?id=68a0c87235b84f382b1168e7694007816c42ced2
Submitter: Jenkins
Branch: master

commit 68a0c87235b84f382b1168e7694007816c42ced2
Author: Edward Hope-Morley <email address hidden>
Date: Wed Oct 4 21:39:14 2017 +0100

    Do relation consistency sweep on leader change

    The current charm design is to perform a sweep of all units
    related on the identity-service interface to ensure that
    they have all the correct setting values applied. If the
    leader unit is deleted and a new one is elected this will
    not happen until some event e.g. config-changed occurs. This
    can result in remote units malfunctioning since they think they
    are not configured. We resolve this by always doing a sweep when
    the leader-elected hook fires.

    Also fixes infinite loop edge case when ssl-cert-master switches
    as a result of leader switch.

    Change-Id: Icd68cc70d81d7d518c918e831056f686dbc7db1e
    Closes-Bug: 1721269

[Edward Hope-Morley (hopem)]

The patch landed surfaced an issue with haproxy not being restarted properly and this his also been fixed and merged in https://review.openstack.org/#/c/510873/. If we backport this patch we will need both.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/17.08
Review: https://review.openstack.org/511239

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/511239
Committed: https://git.openstack.org/cgit/openstack/charm-keystone/commit/?id=9953530f2633717f62469a573d1e3783fdc9f471
Submitter: Jenkins
Branch: stable/17.08

commit 9953530f2633717f62469a573d1e3783fdc9f471
Author: Edward Hope-Morley <email address hidden>
Date: Wed Oct 4 21:39:14 2017 +0100

    Do relation consistency sweep on leader change

    The current charm design is to perform a sweep of all units
    related on the identity-service interface to ensure that
    they have all the correct setting values applied. If the
    leader unit is deleted and a new one is elected this will
    not happen until some event e.g. config-changed occurs. This
    can result in remote units malfunctioning since they think they
    are not configured. We resolve this by always doing a sweep when
    the leader-elected hook fires.

    Also fixes infinite loop edge case when ssl-cert-master switches
    as a result of leader switch.

    Also includes cherry-pick of commit:
    - ID: a59de539edbfc615de0edcef775e2a3fdf7608d9
    - Title: Fix issue with haproxy not restarted

    Change-Id: Icd68cc70d81d7d518c918e831056f686dbc7db1e
    Closes-Bug: 1721269
    (cherry picked from commit 68a0c87235b84f382b1168e7694007816c42ced2)