Hello! I think this is a good idea. We already had problems with ClusterGroups that won't recompute until PME, or which become invalid after PME. Relying on string labels would fix all that.
I can think of a node filter which can't be replaced with label filter (e.g. the one checking for presence of some partition) but generally that's a Bad Idea. Regards, -- Ilya Kasnacheev чт, 1 авг. 2019 г. в 18:47, Pavel Kovalenko <jokse...@gmail.com>: > Hello Igniters, > > I would like to start a discussion about simplifying NodeFilter > functionality. > At the moment NodeFilter's are used to control Caches and Services > distribution across nodes. > In most cases, NodeFIlter implementation seeks for a specific attribute in > NodeAttributes map. If the attribute is found on a node, Cache or Service > is deployed on that node. > However, current NodeFilter interface gives a user much more ways to adjust > such distribution. This gives more flexibility for configuration on the one > hand but it increases complexity and understanding of the API. > Because NodeFilter is a functional interface and configured on the user > side there are problems with serialization, class loading and consistency > check of such objects. > Here is a couple of problems we have with NodeFilter: > 1. User-defined node filter classes must be deployed on all nodes whether > or nor they required on them. This increases the complexity of resolving > problems like in IGNITE-1903. > 2. Part of consistency checking of CacheConfigurations based on NodeFilter > classes comparison, not on objects. User may use the same class for > NodeFilter but with different constructor parameters and this can lead to > inconsistent behavior of the same node filter on different nodes while > consistency check will pass. > 3. We can resolve p.2 using objects equality approach, but we can't force > users to properly implement .equals() method on NodeFilter class. We can > only recommend doing that thing. If the user forgot to implement .equals() > or did it incorrectly we can't deal anything with it. > All of those problems can lead to cluster instability and unpredictable > behavior. > > Instead of continuing using NodeFilter we can give more safe and simpler > way to implement the same feature. I propose the following approach that is > used in many other distributed systems: > User may tag every Ignite node configuration with a specific label that > will be placed in NodeAttributes map. > NodeFilter interface replaced with just a string label. If a node > NodeAttributes map contains such label a Cache or Service will be deployed > on that node and not deployed if the label doesn't exist. > > I would like to add this change to Ignite 3.0 scope because it's an > important and major change in public API. > > WDYT? >
