We are no longer monitoring this channel, please join Slack! https://join.slack.com/t/atomixio/shared_invite/enQtNDgzNjA5MjMyMDUxLTVmMThjZDcxZDE3ZmU4ZGYwZTc2MGJiYjVjMjFkOWMyNmVjYTc5YjExYTZiOWFjODlkYmE2MjNjYzZhNjU2MjY

Hmm... what if we rename CORE and DATA nodes to STATIC and DYNAMIC or PERSISTENT and EPHEMERAL. This is looking at cluster management as independent from storage/replication. The requirements of Raft are that the membership not dynamically evolve, so we just need node types that meet those requirements. STATIC/PERSISTENT nodes would always exist in the configuration whether dead or alive until removed, and DYNAMIC/EPHEMERAL nodes are either alive or not members of the cluster.

Also would like to decouple the system partition from the node types as well and perhaps allow a system partition/group to be provided.

With that done, I also think it could be useful to have some sort of abstraction that provides common configurations. My concern is that the decoupling of the protocols from primitives makes it more complicated to configure Atomix and its primitives, and it would be nice to have a high level abstraction that provides e.g. an enum or something for common configurations (i.e. a configuration for large scale data, for f+1 fault tolerance, for strong consistency/coordination, etc and consistency/persistence/performance based configurations for primitives).

Not sure what that would look like yet

Something that provides a high level API that doesn’t require understanding distributed systems protocols to get the desired behavior

@kuujo thanks for your reply. i got it working now. took me a while to figure out how services, primitives and proxys exactly interact but i got it :smile: great to see you making progress with this project!

@kuujo just moved from 2.1.0-beta2 to 2.1.0-beta3 , removed obsolete "Endpoint" imports and usages, compiled everything fine, started services and found in logs Unknown partition group type: multi-primary
io.atomix.utils.ConfigurationException: Unknown partition group type: multi-primary . Have not found answer in currently cut "getting started section" on website.

re STATIC and DYNAMIC vs PERSISTENT and EPHEMERAL, The latter makes me think more about the storage persistance rather than cluster membership, so from that perspective, I like STATIC and DYNAMIC more.

@junzhai the DistributedLock will be granted to the longest waiting process, but we don’t currently have a read/write lock. I always thought that would be cool to have. Just need to add a new primitive for it.

@johnou nodes don’t necessarily have to store data, though, which is why I wanted to move away from the data-centric names. Persistent/ephemeral just happens to apply to data which may make them easier to understand with respect to storing data, but the true meaning is that the nodes are persistent or ephemeral in the cluster configuration, not with respect to data. It should perhaps be feasible to run a cluster without any data storage. That also makes me think we could also get rid of CLIENT nodes as well.

I’d probably keep CLIENT as it’s simpler to understand, though. Clients are really a special type of EPHEMERAL node that can’t be assigned partitions.