Merge lp:~danilo/charms/trusty/haproxy/merge-services-fix into lp:charms/trusty/haproxy
Proposed by
Данило Шеган
Status: | Merged |
---|---|
Merged at revision: | 94 |
Proposed branch: | lp:~danilo/charms/trusty/haproxy/merge-services-fix |
Merge into: | lp:charms/trusty/haproxy |
Diff against target: |
152 lines (+93/-17) 2 files modified
hooks/hooks.py (+53/-17) hooks/tests/test_reverseproxy_hooks.py (+40/-0) |
To merge this branch: | bzr merge lp:~danilo/charms/trusty/haproxy/merge-services-fix |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
David Britton (community) | Approve | ||
Whit Morriss (community) | Needs Fixing | ||
Björn Tillenius (community) | Approve | ||
Review via email: mp+259233@code.launchpad.net |
Description of the change
Merge service backends properly even when new service has fewer backends than the old one
This is a problem we've noticed with Landscape deployments (trying to use multiple backends per unit), and we've started hitting this reliably (see linked bug).
The solution is simple: do not attempt to merge new_service backends which might not exist. Test is included.
Fix has been tested and works properly with landscape-charm at least.
FWIW, I've confirmed on haproxy-
To post a comment you must log in.
I kind of tried to stay away from refactoring the method: I've suspected the problem already, but got tricked by my tests using assertItemsEqual which always passed :/
Now I do a full refactor, stressing readability and correctness over concise code (eg. even dropping use of groupby() to weed out duplicate entries).