-
Notifications
You must be signed in to change notification settings - Fork 414
Add playbook to force consul leader election #948
Conversation
Does this require a consul restart or reload to take effect? We could also populate this file with the inventory data. |
As @ChrisAubuchon noted in #763, "consul.json already has retry_after_leave set. That causes Consul to rejoin." We could definitely repopulate peers.json with inventory data, but since |
@stevendborrelli, @siddharthist is there any more work needed on this? has it been tested? should we add a small doc explaining why you would use this? |
@ryane @siddharthist OS testing in process. Deploying and installing playbook. Are there other tests that should be run? |
@TanyaCouture yes, we definitely want to verify if this playbook will fix a consul cluster that is unable to elect a leader (after a crash, for example) |
|
We should take a look at @abn's playbook for doing this. |
We've had enough folks having issues with consul that adding something similar to @abn's playbook makes sense. I don't think the current PR is sufficient. |
@stevendborrelli I'll update ASAP. |
One thing I had to do in #1338 was modify the peers.json content with a default(groups['all']) for when consul_dc_group is not set. You might want to test with consul_dc_group unset to verify.
|
this is a variant of the playbook that worked for me and for @RaunoVV on gitter. https://gitter.im/CiscoCloud/mantl?at=573398303a05b11b6a4c11e6
added an updated version of the playbook that worked for me and for @RaunoVV on gitter. probably could use more testing/validation |
this has been successfully tested a couple of times and definitely fixes the issue in some scenarios. It is safe to merge now and if we identify other scenarios where it doesn't work, we can create new issues for it. |
See discussion on #763, related to #566