Merge lp:~stub/charms/trusty/cassandra/wait-for-joining into lp:charms/trusty/cassandra
Proposed by
Stuart Bishop
Status: | Merged |
---|---|
Merge reported by: | Stuart Bishop |
Merged at revision: | not available |
Proposed branch: | lp:~stub/charms/trusty/cassandra/wait-for-joining |
Merge into: | lp:charms/trusty/cassandra |
Prerequisite: | lp:~stub/charms/trusty/cassandra/ensure-thrift |
Diff against target: |
116 lines (+36/-17) 2 files modified
hooks/actions.py (+34/-15) tests/test_actions.py (+2/-2) |
To merge this branch: | bzr merge lp:~stub/charms/trusty/cassandra/wait-for-joining |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Cory Johns (community) | Needs Information | ||
Review via email: mp+286993@code.launchpad.net |
Commit message
Make bootstrap procedure safer
Description of the change
We were previously capping the replication factor of the system_auth keyspace to three. I have since found documentation recommending increasing the replication factor so every node has a copy of this data.
Also, a somewhat undocumented caveat to bootstrap is that, at least when using vnodes, only one node should be JOINING at a time. Keep hold of the lock until the bootstrapping node has become NORMAL, which also neatly stops other nodes from rebooting while it is attempting to stream data.
To post a comment you must log in.
Overall this looks good, but I'm a bit concerned about the potential for a deadlock in the charm due to the JOINING / NORMAL wait. Would it be possible to add a timeout to that loop that, if exceeded, puts the charm into a "waiting" state and have it re-try on the next update-status hook?