Actually, after giving it some thought, I now think that the same kind of flexibility can be achieved by giving multiple nodes the same CLUSTER_REGION_ID (don't like the arc id). For example, nodes in 2 racks could be given CLUSTER_REGION_ID of 1 and 2. This way all nodes in rack 1 or rack 2 would be next to each other in the cluster ring.
Do you think we will ever care about the order of nodes within the same region, e.g. does the order of nodes within the same rack matter? D. On Tue, Dec 27, 2016 at 7:30 AM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > > > On Tue, Dec 27, 2016 at 2:32 AM, Alexei Scherbakov < > alexey.scherbak...@gmail.com> wrote: > >> 2016-12-27 10:42 GMT+03:00 Yakov Zhdanov <yzhda...@apache.org>: >> > I think the NodeComparator approach will work. User can chose how to >> sort >> > nodes from one rack before nodes from another rack. Same goes for >> subnets, >> > or data centers. >> > >> >> > >> > Dmitry, can you please explain why you enforce user to write code? This >> > does not seem convenient to me at all. If user wants to write code then >> he >> > can do it for calculating proper arc_id. >> > >> >> Yakov, where is no need to for user to write code. We can provide two >> default Comparator implementations: >> first based on IP address(default), and second based on node attribute. >> User just plugs one of the implementations and adds node attribute to node >> config in second case - let it be ARC_ID by default. > > > Completely agree with Alexey here. NodeComparator sounds like a generic > approach. We can provide various implementations of comparator with > different sorting strategies out of the box. >
