These are chat archives for atomix/atomix

22nd
Apr 2018
Johno Crawford
@johnou
Apr 22 2018 06:48
as long as you don't need to configure 0 partitions on every node it would be ok to drop client imo
Johno Crawford
@johnou
Apr 22 2018 07:06
but speaking about easier setup, I still think node type could be configured using gossip, in the sense that you don't need to define it in the config, just a bunch of ips and ports
Jordan Halterman
@kuujo
Apr 22 2018 09:59
Node types can be learned via gossip, but nodes that are participating in consensus must be explicitly defined on all nodes. This is an unavoidable aspect of consensus. If a node doesn’t know which other nodes are participating in consensus then it doesn’t know how to count votes and that can lead to split brains
So, this will usually lead back to PERSISTENT nodes being explicitly listed anyways
It’s not safe to learn which other nodes are participating in consensus because the learning (gossip) cannot tolerate partitions.
Learning which nodes are participating in consensus basically leads to a non-partition tolerant consensus algorithm
Jordan Halterman
@kuujo
Apr 22 2018 10:04
There’s nothing wrong with learning about PERSISTENT nodes after startup as long as they’re not participating in consensus.
I do think we should remove CLIENT nodes and have just two node types
I also think we should make a Cluster or AtomixCluster class that’s independently runnable without atomix-core. This would provide a class that makes it possible to do cluster management and communication independent of the primitives, and allow us to make assumptions that using the Atomix class indicates intent to use primitives.
Jordan Halterman
@kuujo
Apr 22 2018 10:14
There’s probably nothing wrong with EPHEMERAL nodes participating in consensus, and that makes it feasible to learn about node types assuming at least the Address for those nodes is provided at startup. But we’d still need to have some way to indicate which nodes are participating in consensus at startup, and no consensus node can be missing. But the semantics of PERSISTENT nodes make sense for consensus anyways. That is, even though a node is not alive it’s still part of the cluster and is counted towards votes.
The current configuration is exactly what you’d get with any consensus-based system: when consensus is used, the consensus (PERSISTENT) nodes must be explicitly listed at startup. Non-consensus (EPHEMERAL) nodes don’t have to be listed at all and can be discovered via the consensus nodes.
If there are no consensus nodes then no nodes have to be listed at all and they can be discovered instead.
Jordan Halterman
@kuujo
Apr 22 2018 10:25
We’ll see how this turns out after making the cluster/partition configuration changes...
Johno Crawford
@johnou
Apr 22 2018 11:09
Makes sense