Merge lp:~gnuoy/charms/trusty/mysql/lp-1353135 into lp:charms/trusty/mysql
Status: | Merged |
---|---|
Merged at revision: | 125 |
Proposed branch: | lp:~gnuoy/charms/trusty/mysql/lp-1353135 |
Merge into: | lp:charms/trusty/mysql |
Diff against target: |
102 lines (+38/-3) 2 files modified
hooks/common.py (+3/-1) hooks/shared_db_relations.py (+35/-2) |
To merge this branch: | bzr merge lp:~gnuoy/charms/trusty/mysql/lp-1353135 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Review Queue (community) | cbt | Approve | |
Cory Johns (community) | Approve | ||
charmers | Pending | ||
Review via email: mp+230932@code.launchpad.net |
Description of the change
Set a list of allowed_units which the client units can query to see if their permissions have been setup yet. The reason for this is to allow the client to work around a race condition which occurs when a service has multiple units:
1) A service consisting of multiple units joins mysql and triggers mysql to run shared-db-changed for each unit in turn. But as soon as shared-db-changed has been run for the *first* time mysql runs relation set publishing the password.
2) All units in the client service then run their shared-db-changed hook in response to the relation set that mysql issued when it did the *first* run of shared-db-changed. At this point permissions have only been granted to one unit and the rest will fail if they try and access the db.
This is the same behaviour as the postgres charm which was added in response to Bug #1187508
Liam,
Thank you for this fix. It looks good and works as expected, though the affected charms will need to be updated to make use of the new field, of course (the charm I was testing this with errored and blocked the list from being fully updated, but one unit did get the full list and another unit got a partial list before being blocked by the other units failing).