Default names for peers about raft

[bitwalker]

You'd want unquote(__CALLER__.module) rather than unquote(__MODULE__), and you don't want to expand the call to node(), but that wasn't your question :P

I'm not sure I follow on the set_configuration bit, are you saying it would be a macro which expands to something effectively like Raft.really_set_configuration(leader, [{KVStore, :"a@mymachine"}, ...])?

It might instead make more sense to have set_configuration take 3 arguments, the leader, the Raft module (i.e. KVStore in your example), and then the node list, and internally apply the Raft module to each element of the node list. This would be equivalent to saying "build a Raft cluster with members named KVStore running on nodes A, B, and C". Then you take care of joining the name with the node to form the tuple for communicating with those processes. Since the Raft module is a key part of the API, I'm not sure hiding it will always be viable, it is probably desirable to make things explicit, but make the API convenient enough, that you don't have to do something like wrap every node name in a tuple with the Raft module. Things get tricky though if you want to support some kind of process registry using {:via, registry, name}, because then you need to explicitly provide those tuples as elements of the list; but you could support a hybrid list, where plain atoms are paired with the module name to get the {name, node} pair, and anything else is treated as-is, so that you could either use the convenient API, or provide a list of via tuples if that's what you need. It still feels less than perfect, but I'm mostly spitballing ideas here.

I don't yet have a strong opinion on this though until I have a chance to do some experimentation, but just conceptually this is my two cents, hope that is the feedback you were looking for :)

[keathley]

Stepping back, the whole reason I wanted to consider this was to make it easier to specify clusters, add new peers, etc. I'm not sure that this implementation is going to really satisfy that goal in the best way. Its probably better to see how #4 pans out and then evaluate after that.

[keathley]

Closing this for now because I think this issue will be mitigated in #4.