lp://qastaging/~corey.bryant/charms/trusty/mysql/render
- Get this branch:
- bzr branch lp://qastaging/~corey.bryant/charms/trusty/mysql/render
Branch merges
- Tim Van Steenburgh (community): Approve
- Review Queue (community): Approve (automated testing)
- OpenStack Charmers: Pending requested
-
Diff: 31 lines (+0/-15)1 file modifiedhooks/lib/utils.py (+0/-15)
Branch information
- Owner:
- Corey Bryant
- Status:
- Development
Recent revisions
- 129. By Liam Young
-
[gnuoy,
r=james- page] Sync charmhelpers to make distro a valid source option again - 127. By David Britton
-
resync charmhelpers, add makefile targets to speed up future syncs [r=dpb] [a=tribaal]
- 126. By Charles Butler
-
Charles Butler 2014-09-19 Correct linting issue in db_relation py
Antonio Rosales 2014-09-17 Add default key values.
Jorge Castro 2014-08-13 [merge] [dweaver] Fix for bug 1314763. Changed the master-rel... - 125. By James Page
-
[gnuoy,
r=james- page,t= james-page] Set allowed_hosts data on shared-db relations 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
Branch metadata
- Branch format:
- Branch format 7
- Repository format:
- Bazaar repository format 2a (needs bzr 1.16 or later)
- Stacked on:
- lp://qastaging/charms/mysql