designate charm still causes haproxy to run after an update-status

[Alex Kavanagh]

The designate charm during an update-status, when nothing has changed, still writes to the haproxy relation causing the haproxy charm to write its configuration files and check whether it's clustered, etc. as though new information had come on the haproxy relation.

Essentially, the designate charm is still doing too much work due to reactive running all the 'condition-true' handlers, which for designate means, writing to haproxy as the last thing it does when all the interfaces are ready.

Either, the designate charm should gate the handler from running during update status, or, determine if any of the data on the haproxy relation has changed and ONLY set it if it has, thus stopping haproxy from running due to relation data. It's possible that it's dictionary data, whose order is changing.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/491526
Committed: https://git.openstack.org/cgit/openstack/charm-designate/commit/?id=1ef3522f86caa1275ba96553dc6d8ffe08a9a99d
Submitter: Jenkins
Branch: master

commit 1ef3522f86caa1275ba96553dc6d8ffe08a9a99d
Author: Alex Kavanagh <email address hidden>
Date: Mon Aug 7 16:46:11 2017 +0100

    Do less work in the update-status hook

    This patchset, along with the corresponding ones in charms.openstack
    and interface-hacluster reduce the amount of work that the charm does
    during an update-status hook. This also fixes the issue where an
    update-status hook triggered activity in the hacluster subordinate due
    to data being set on the interface. There is still work to be done in
    this area, as the configs for the charm are still being written on every
    update-status hook, although this doesn't result in a restart of any of
    the services. This probably requires a re-think of how the
    charm-helpers function runs; patch to charm-helpers coming up soon.

    This also fixes bug 1712973 where the update-pools command with empty
    pools errors causing the charm to error out and fail. This is
    undesirable, so this condition is caught and logged instead.

    Change-Id: I6db68a479dc903ce620ba62c1898247f71d14701
    Depends-On: I3717387d1d8d2ab875d51f262efd1df7f2529689
    Depends-On: I750f3c41a2f0447a47cfd19bab1d4958de4577f2
    Closes-Bug: #1708396
    Closes-Bug: #1712973