Logs show the most recently restarted node as elected leader, despite weights

[angadsingh]

Describe the bug I have a 2 node setup - node1 and node2. I have set one of the nodes (node1) to have a weight of 20, which I prefer to become the leader, and the other (node2) to 10. Because of another issue (https://github.com/mKeRix/room-assistant/issues/262), i ended up specifying the peerAddresses inside cluster config, after which leader gets elected correctly. So, after i start both the nodes, I can see that the leader gets correctly as node1 when i hit the /entities API on both the nodes. Perfect. But whenever i restart one of the nodes, the log on the other node shows that the other has become the leader - even though the API shows the correct election:

[{
    "attributes": {
        "nodes": ["node2, "node1"]
    },
    "id": "status-cluster-size",
    "name": "node1 Cluster Size",
    "distributed": false,
    "state": 2
}, {
    "attributes": {
        "quorumReached": true
    },
    "id": "status-cluster-leader",
    "name": "node1 Cluster Leader",
    "distributed": false,
    "state": "node1"
}]

[{
    "attributes": {
        "nodes": ["node1, "node2"]
    },
    "id": "status-cluster-size",
    "name": "node2 Cluster Size",
    "distributed": false,
    "state": 2
}, {
    "attributes": {
        "quorumReached": true
    },
    "id": "status-cluster-leader",
    "name": "node2 Cluster Leader",
    "distributed": false,
    "state": "node1"
}]

To reproduce Setup up two nodes as per the config below Start/restart both nodes - leader will be elected properly, as per the entities API Restart one of the nodes - logs will show that leader as elected, even though API shows the correct leader, as per weight

Relevant logs

8/12/2020, 3:49:37 PM - info - ClusterService: node2has been elected as leader

Relevant configuration

node1

global:
  instanceName: node1
  integrations:
    - bluetoothLowEnergy
    - homeAssistant
cluster:
  weight: 20
  autoDiscovery: false
  peerAddresses:
    - '192.168.1.19:6425'
    - '192.168.1.67:6425'
homeAssistant:
  mqttUrl: 'mqtt://192.168.1.19:1883'
  mqttOptions:
    username: mqtt
    password: <password>
bluetoothLowEnergy:
  whitelist:
    - ee01b5455f23
entities:
  behaviors:
    ble-ee01b5455f23-tracker:
      debounce:
        wait: 5
        maxWait: 30

node2

global:
  instanceName: node2
  integrations:
    - bluetoothLowEnergy
    - homeAssistant
cluster:
  weight: 10
  autoDiscovery: false
  peerAddresses:
    - 192.168.1.19:6425
    - 192.168.1.67:6425
homeAssistant:
  mqttUrl: 'mqtt://192.168.1.19:1883'
  mqttOptions:
    username: mqtt
    password: <password>
bluetoothLowEnergy:
  whitelist:
    - ee01b5455f23
  maxDistance: 3
entities:
  behaviors:
    ble-ee01b5455f23-tracker:
      debounce:
        wait: 5
        maxWait: 30

Expected behavior Logs should show the same leader as the API

Environment

• room-assistant version: 2.8.2
• installation type: node1 on Hass.io, node2 on NodeJS
• hardware: node1 on Raspberry Pi 4B, node2 on Raspberry Pi Zero W
• OS: node2 on Raspberry OS

[mKeRix]

Yeah, I fear the leader election needs some work and I probably either need to fork the underlying library or build something else for this. Thanks for the detailed issue reports!

[github-actions[bot]]

There hasn't been any activity on this issue recently. In an effort to provide a better overview of current issues we automatically clean some of the old ones. Many of them may already be resolved in newer versions of room-assistant. This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.