Redesign node name preferred functionality
There was an old ticket that already describes the desired behavior, but it is much more complicated than expected.
https://www.assembla.com/spaces/akka/tickets/989-allow-specifying-preferred-nodes-of-other-type-than--node--name--
We need to redesign this part:
- we need to configure out a good canonical form of storing the information
- we need to make sure that if something is stored internally on a node about this information, and the cluster topology changes, that the internals get updated (depending on the canonical format selected)
- we need to deal with ambiguous nodes: so what if more than one node wants to have the same canonical form
- we also need to deal with ipv6
- we need to think about metadata. E.g. instead of saying: I want node1,node2 as preferred node, it would be nicer if you can say: I want nodes that are optimized for cpu are used for this set of actors. Using metadata allows to scale up to 1000's of nodes, since you don't need to deal with nodes individually. If you make sure that the ip adres/host name/node name always is available in the metadata, you could say
preferred node = contains(mp3) and not contains(mpeg) and not contains(1.2.3.4:80).. So you have an extremely flexible solution where even the old solutions are still being possible. In my book that kicks ass!
So this is not a task that directly can be picked up.. it needs us all agreeing upon a solution, and then we can create a new bunch of concrete tickets. This is more like a theme thing.
https://www.assembla.com/spaces/akka/tickets/989-allow-specifying-preferred-nodes-of-other-type-than--node--name--
We need to redesign this part:
- we need to configure out a good canonical form of storing the information
- we need to make sure that if something is stored internally on a node about this information, and the cluster topology changes, that the internals get updated (depending on the canonical format selected)
- we need to deal with ambiguous nodes: so what if more than one node wants to have the same canonical form
- we also need to deal with ipv6
- we need to think about metadata. E.g. instead of saying: I want node1,node2 as preferred node, it would be nicer if you can say: I want nodes that are optimized for cpu are used for this set of actors. Using metadata allows to scale up to 1000's of nodes, since you don't need to deal with nodes individually. If you make sure that the ip adres/host name/node name always is available in the metadata, you could say
preferred node = contains(mp3) and not contains(mpeg) and not contains(1.2.3.4:80).. So you have an extremely flexible solution where even the old solutions are still being possible. In my book that kicks ass!
So this is not a task that directly can be picked up.. it needs us all agreeing upon a solution, and then we can create a new bunch of concrete tickets. This is more like a theme thing.
Leave a comment