Merge ~mariosplivalo/charm-mongodb:bionic-fix into ~mongodb-charmers/charm-mongodb:master
Proposed by Mario Splivalo
Status: | Merged | ||||
---|---|---|---|---|---|
Merged at revision: | 001d9b56d9597c8b20dc3b5b8cf7927a12a243b2 | ||||
Proposed branch: | ~mariosplivalo/charm-mongodb:bionic-fix | ||||
Merge into: | ~mongodb-charmers/charm-mongodb:master | ||||
Diff against target: | 67 lines (+11/-9) 2 files modified hooks/hooks.py (+8/-7) metadata.yaml (+3/-2) | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Tom Haddon (community) | Approve | ||
Stuart Bishop (community) | Approve | ||
Review via email: |
Commit message
Fixes replicaset initialization for Bionic.
Also, uses leader-election to figure out the unit to initialize replicaset on.
Fixes-bug: LP: #1748214
Description of the change
Fixes replicaset initialization for Bionic.
Also, uses leader-election to figure out the unit to initialize replicaset on.
To post a comment you must log in.
Using leadership here is correct. If I understand this correctly, when the lead unit runs its replica- set-relation- changed hook, it initializes the replica set using init_replset(). As a side effect, this also makes it the primary for the replica set so it will then add the remote unit. Non-leaders and non-primaries do nothing.
Technically, there is a race here. It possible for all units to join and setup the relation while none of them are leader. It is fairly improbable, as it involves leadership elections happening at the right time to ensure that leadership is handed to a unit after it has run the relation joined/changed hooks (requires at least two netsplits occuring at the right point in the sequence). If you want to avoid this, you need a leader-elected hook that iterates over all the existent relations and initializes them if necessary. This race would be hard to have in a reactive charm, but this isn't reactive.
The replica set initialization will happen multiple times (at least once per unit), so hopefully it is idempotent and lightweight. The existing charm does the same thing so I suspect this is fine. Similarly, join_replset will be called multiple times for each unit and also needs to be idempotent.
I personally wouldn't be committing to artful support at this stage, so unless we have a reason to be making artful deploys I'd remove that. And xenial should be first in the list of supported series, since we want that to be the default.