Allow specifying persistent peer ids

[sinkingpoint]

Currently the default behaviour is to generate a new, random peer id on every startup. This makes clustering a bit weird, so this commit adds in an optional cli arg that allows specifying a custom peer id that we can persist across runs

This addresses #2285

Signed-off-by: sinkingpoint [email protected]

[sinkingpoint]

Thanks for the review @simonpasquier ! I've added in an acceptance test to test the behaviour. Detecting duplicate names is an interesting problem... Yes - we can implement the ConflictDelegate interface, but the question is what to do with that information - we can log it (easy), or attempt to shut down one of the duplicates, but that, in practice gets a bit messy. In particular, identifying which peer is the "invalid" one is kind of difficult - memberlist doesn't have the idea of an "authoritative" node for a given name

[simonpasquier]

Sorry for the lag (PTO interruption on my side). I agree that there's no practical that we can decide which peer is more legitimate than the other. I think that logging the issue + adding a metric/alert would be good enough. WDYT?

[sinkingpoint]

Apologies for leaving this... I think that sounds reasonable. Will push that today