When Overseer node goes down then depending on the current phase of trigger execution a nodeLost event may not have been generated. Similarly, when a new node is added and Overseer goes down before the trigger saves a checkpoint (and before it produces nodeAdded event) this event may never be generated.
The proposed solution would be to modify how nodeLost / nodeAdded information is recorded in the cluster:
- new nodes should do a ZK multi-write to both /live_nodes and additionally to a predefined location eg. /autoscaling/nodeAdded/<nodeName>. On the first execution of Trigger.run in the new Overseer leader it would check this location for new znodes, which would indicate that node has been added, and then generate a new event and remove the znode that corresponds to the event.
- node lost events should also be recorded to a predefined location eg. /autoscaling/nodeLost/<nodeName>. Writing to this znode would be attempted simultaneously by a few randomly selected nodes to make sure at least one of them succeeds. On the first run of the new trigger instance (in new Overseer leader) event generation would follow the sequence described above.