designate charm still causes haproxy to run after an update-status
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Designate Charm |
Fix Released
|
High
|
Alex Kavanagh |
Bug Description
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.
Changed in charm-designate: | |
importance: | Undecided → High |
status: | New → Triaged |
Changed in charm-designate: | |
assignee: | nobody → Alex Kavanagh (ajkavanagh) |
milestone: | none → 17.08 |
Changed in charm-designate: | |
status: | Fix Committed → Fix Released |
Fix proposed to branch: master /review. openstack. org/491526
Review: https:/