Re: Replacing NodeFilter functionality with label approach
Folks, I feel that the picture still is not clear for the subject. Pavel K., could you please highlight problems related to user code in NodeFilter except classloading? Nikolay, could you please provide some examples when node filtering cannot be solved with label/regexp approach? чт, 8 авг. 2019 г. в 15:39, Pavel Tupitsyn : > > I agree that attribute-based filtering is enough. > > We should get rid of predicates in configuration as much as possible: > they introduce a lot of complexity for other platforms (.NET), among other > things mentioned above. > > On Thu, Aug 8, 2019 at 2:04 PM Pavel Kovalenko wrote: > > > Ivan, > > > > > And there is also one idea (I am not fan of it but still). Can we use > > > some kind of scripting for nodes filtering? In that case node filter > > > is represented by script string, e.g. javascript. > > > > I guess it can lead to the same situation as in Java NodeFilter's. We can't > > control what happens in a filter in this case. > > We can consider regex as an option instead of just labels. It's still > > string and can be validated on correctness during node start. > > But we still don't have any real examples that require more flexibility > > than labels have. > > > > вт, 6 авг. 2019 г. в 14:46, Павлухин Иван : > > > > > Alexey, > > > > > > It seems that a problem has a solution with using 2 attributes or 2 > > > labels. Is not it more clear than using custom code? > > > > > > Folks, > > > > > > > I don't think we should take "hard to implement" as an argument in this > > > discussion :) > > > Did not fully get the point. KISS principle is not true anymore? Or is > > > this discussion somehow special? I believe that every flexibility > > > handle should be critically justified. Would be great to justify > > > NodeFilter flexibility. > > > > > > > Filters based of hostname or ip address. > > > Is it a good idea to use IP address for node filtering? IP can be > > > changed for a node with persistence, does it mean that not relevant > > > data (according to a filter) should be cleared, does it work now? > > > > > > And there is also one idea (I am not fan of it but still). Can we use > > > some kind of scripting for nodes filtering? In that case node filter > > > is represented by script string, e.g. javascript. > > > > > > вт, 6 авг. 2019 г. в 12:22, Alexey Kukushkin > >: > > > > > > > > Pavel, > > > > > > > > Just a real example you asked for: we have a user attribute "ROLE_DC", > > > > which is a comma separated list like "wfe_a, as_a, db_a" (server role > > and > > > > data center designator) and we have node filters to deploy services and > > > > start caches on servers with specific role (like WFE) and sometimes > > > > specific role and DC (like WFE_A). The node filter splits the list and > > > uses > > > > a regular expression to match each segment. > > > > > > > > If you replace generic node filter with a user attribute filter then we > > > > still can achieve what we need by creating 3 user attributes (ROLE_DC, > > > > ROLE and DC) but we lose flexibility since now adding a new data center > > > > requires updating all cache and service configurations. With regex > > > matching > > > > we do not need to update the configurations since we still match all > > the > > > > roles in the new DC. > > > > > > > > So we would have a solution with user attributes filter but I we lose > > > some > > > > flexibility. > > > > > > > > -- > > > > Best regards, > > > > Alexey > > > > > > > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > -- Best regards, Ivan Pavlukhin
Re: Replacing NodeFilter functionality with label approach
I agree that attribute-based filtering is enough. We should get rid of predicates in configuration as much as possible: they introduce a lot of complexity for other platforms (.NET), among other things mentioned above. On Thu, Aug 8, 2019 at 2:04 PM Pavel Kovalenko wrote: > Ivan, > > > And there is also one idea (I am not fan of it but still). Can we use > > some kind of scripting for nodes filtering? In that case node filter > > is represented by script string, e.g. javascript. > > I guess it can lead to the same situation as in Java NodeFilter's. We can't > control what happens in a filter in this case. > We can consider regex as an option instead of just labels. It's still > string and can be validated on correctness during node start. > But we still don't have any real examples that require more flexibility > than labels have. > > вт, 6 авг. 2019 г. в 14:46, Павлухин Иван : > > > Alexey, > > > > It seems that a problem has a solution with using 2 attributes or 2 > > labels. Is not it more clear than using custom code? > > > > Folks, > > > > > I don't think we should take "hard to implement" as an argument in this > > discussion :) > > Did not fully get the point. KISS principle is not true anymore? Or is > > this discussion somehow special? I believe that every flexibility > > handle should be critically justified. Would be great to justify > > NodeFilter flexibility. > > > > > Filters based of hostname or ip address. > > Is it a good idea to use IP address for node filtering? IP can be > > changed for a node with persistence, does it mean that not relevant > > data (according to a filter) should be cleared, does it work now? > > > > And there is also one idea (I am not fan of it but still). Can we use > > some kind of scripting for nodes filtering? In that case node filter > > is represented by script string, e.g. javascript. > > > > вт, 6 авг. 2019 г. в 12:22, Alexey Kukushkin >: > > > > > > Pavel, > > > > > > Just a real example you asked for: we have a user attribute "ROLE_DC", > > > which is a comma separated list like "wfe_a, as_a, db_a" (server role > and > > > data center designator) and we have node filters to deploy services and > > > start caches on servers with specific role (like WFE) and sometimes > > > specific role and DC (like WFE_A). The node filter splits the list and > > uses > > > a regular expression to match each segment. > > > > > > If you replace generic node filter with a user attribute filter then we > > > still can achieve what we need by creating 3 user attributes (ROLE_DC, > > > ROLE and DC) but we lose flexibility since now adding a new data center > > > requires updating all cache and service configurations. With regex > > matching > > > we do not need to update the configurations since we still match all > the > > > roles in the new DC. > > > > > > So we would have a solution with user attributes filter but I we lose > > some > > > flexibility. > > > > > > -- > > > Best regards, > > > Alexey > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > >
Re: Replacing NodeFilter functionality with label approach
Ivan, > And there is also one idea (I am not fan of it but still). Can we use > some kind of scripting for nodes filtering? In that case node filter > is represented by script string, e.g. javascript. I guess it can lead to the same situation as in Java NodeFilter's. We can't control what happens in a filter in this case. We can consider regex as an option instead of just labels. It's still string and can be validated on correctness during node start. But we still don't have any real examples that require more flexibility than labels have. вт, 6 авг. 2019 г. в 14:46, Павлухин Иван : > Alexey, > > It seems that a problem has a solution with using 2 attributes or 2 > labels. Is not it more clear than using custom code? > > Folks, > > > I don't think we should take "hard to implement" as an argument in this > discussion :) > Did not fully get the point. KISS principle is not true anymore? Or is > this discussion somehow special? I believe that every flexibility > handle should be critically justified. Would be great to justify > NodeFilter flexibility. > > > Filters based of hostname or ip address. > Is it a good idea to use IP address for node filtering? IP can be > changed for a node with persistence, does it mean that not relevant > data (according to a filter) should be cleared, does it work now? > > And there is also one idea (I am not fan of it but still). Can we use > some kind of scripting for nodes filtering? In that case node filter > is represented by script string, e.g. javascript. > > вт, 6 авг. 2019 г. в 12:22, Alexey Kukushkin : > > > > Pavel, > > > > Just a real example you asked for: we have a user attribute "ROLE_DC", > > which is a comma separated list like "wfe_a, as_a, db_a" (server role and > > data center designator) and we have node filters to deploy services and > > start caches on servers with specific role (like WFE) and sometimes > > specific role and DC (like WFE_A). The node filter splits the list and > uses > > a regular expression to match each segment. > > > > If you replace generic node filter with a user attribute filter then we > > still can achieve what we need by creating 3 user attributes (ROLE_DC, > > ROLE and DC) but we lose flexibility since now adding a new data center > > requires updating all cache and service configurations. With regex > matching > > we do not need to update the configurations since we still match all the > > roles in the new DC. > > > > So we would have a solution with user attributes filter but I we lose > some > > flexibility. > > > > -- > > Best regards, > > Alexey > > > > -- > Best regards, > Ivan Pavlukhin >
Re: Replacing NodeFilter functionality with label approach
Alexey, It seems that a problem has a solution with using 2 attributes or 2 labels. Is not it more clear than using custom code? Folks, > I don't think we should take "hard to implement" as an argument in this > discussion :) Did not fully get the point. KISS principle is not true anymore? Or is this discussion somehow special? I believe that every flexibility handle should be critically justified. Would be great to justify NodeFilter flexibility. > Filters based of hostname or ip address. Is it a good idea to use IP address for node filtering? IP can be changed for a node with persistence, does it mean that not relevant data (according to a filter) should be cleared, does it work now? And there is also one idea (I am not fan of it but still). Can we use some kind of scripting for nodes filtering? In that case node filter is represented by script string, e.g. javascript. вт, 6 авг. 2019 г. в 12:22, Alexey Kukushkin : > > Pavel, > > Just a real example you asked for: we have a user attribute "ROLE_DC", > which is a comma separated list like "wfe_a, as_a, db_a" (server role and > data center designator) and we have node filters to deploy services and > start caches on servers with specific role (like WFE) and sometimes > specific role and DC (like WFE_A). The node filter splits the list and uses > a regular expression to match each segment. > > If you replace generic node filter with a user attribute filter then we > still can achieve what we need by creating 3 user attributes (ROLE_DC, > ROLE and DC) but we lose flexibility since now adding a new data center > requires updating all cache and service configurations. With regex matching > we do not need to update the configurations since we still match all the > roles in the new DC. > > So we would have a solution with user attributes filter but I we lose some > flexibility. > > -- > Best regards, > Alexey -- Best regards, Ivan Pavlukhin
Re: Replacing NodeFilter functionality with label approach
Pavel, Just a real example you asked for: we have a user attribute "ROLE_DC", which is a comma separated list like "wfe_a, as_a, db_a" (server role and data center designator) and we have node filters to deploy services and start caches on servers with specific role (like WFE) and sometimes specific role and DC (like WFE_A). The node filter splits the list and uses a regular expression to match each segment. If you replace generic node filter with a user attribute filter then we still can achieve what we need by creating 3 user attributes (ROLE_DC, ROLE and DC) but we lose flexibility since now adding a new data center requires updating all cache and service configurations. With regex matching we do not need to update the configurations since we still match all the roles in the new DC. So we would have a solution with user attributes filter but I we lose some flexibility. -- Best regards, Alexey
Re: Replacing NodeFilter functionality with label approach
Nikolay,
> Filters based of hostname or ip address.
Hostname or IP address can be injected to Ignite configuration as labels
(NodeAttributes) without dynamic lookup necessary.
> I don't think we should take "hard to implement" as an argument in this
discussion :)
> Seems, whole Ignite peer class loading design need to be improved.
I think that code simplification, reducing the complexity of future support
and reducing number of possible bugs can be arguments :)
> This is common issue to every user-provided code.
> Wrong implementation of affininty function is one the examples that comes
in the mind.
But it doesn't mean that we should do nothing with it. As fewer, we have
possibilities of injecting user-provided code without strict necessary, as
the more durable and predictable product we have as a result.
WDYT?
пн, 5 авг. 2019 г. в 17:56, Nikolay Izhikov :
> Pavel.
>
> > I don't see yet any practical cases with NodeFilter that can't be
> resolved
> > using just labels.
>
> Filters based of hostname or ip address.
>
> > 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.
>
> I don't think we should take "hard to implement" as an argument in this
> discussion :)
> Seems, whole Ignite peer class loading design need to be improved.
>
> > 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.
>
> This is common issue to every user-provided code.
> Wrong implementation of affininty function is one the examples that comes
> in the mind.
>
> I think flexibility is good thing, so I'm -1 to reduce it.
>
> What do you think?
>
> В Пн, 05/08/2019 в 17:35 +0300, Pavel Kovalenko пишет:
> > Nikolay,
> >
> > Thank you for your feedback.
> > Could you please tell more about cases when custom node filter that not
> > relies on node attributes may be used?
> > For me, it's flexibility just for flexibility that introduces problems
> > described in the topic.
> > I don't see yet any practical cases with NodeFilter that can't be
> resolved
> > using just labels.
> >
> >
> >
> > пн, 5 авг. 2019 г. в 16:28, Nikolay Izhikov :
> >
> > > Ivan,
> > >
> > > ~Mail~ Talks are cheap! Show me the code (C) :)
> > >
> > >
> > > class NodeAttributeFilter implements IgnitePredicate {
> > > private String name;
> > > private T value;
> > >
> > >
> > > public boolean apply(ClusterNode n) {
> > > return Objects.equals(n.attribute(name), value);
> > > }
> > >
> > > //...setters, getters.
> > > }
> > >
> > >
> > > В Пн, 05/08/2019 в 16:11 +0300, Павлухин Иван пишет:
> > > > Hi Nikolay,
> > > >
> > > > Could you please elaborate how will NodeAttributeFilter behave? Do
> you
> > > > mean specifying attribute name and value for exact comparison inside?
> > > > Without any dynamic (user) code involved?
> > > >
> > > > Also I it is quite interesting for me what flexibility you are
> > > > thinking about? I think that the topic is quite important and it
> would
> > > > be great to collect use cases and describe best practices in
> > > > documentation.
> > > >
> > > > пн, 5 авг. 2019 г. в 15:38, Nikolay Izhikov :
> > > > >
> > > > > Hello, Pavel.
> > > > >
> > > > > I think we shouldn't reduce flexibility of NodeFilter.
> > > > > So, I am -1 to remove it in Ignite 3.
> > > > >
> > > > > Instead, Ignite can provide NodeAttributeFilter implementation of
> > >
> > > NodeFilter.
> > > > > Seems, it will resolve all described issues.
> > > > >
> > > > >
> > > > > В Чт, 01/08/2019 в 19:33 +0300, Ilya Kasnacheev пишет:
> > > > > > 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,
> > > >
> > > >
> > > >
>
Re: Replacing NodeFilter functionality with label approach
Pavel.
> I don't see yet any practical cases with NodeFilter that can't be resolved
> using just labels.
Filters based of hostname or ip address.
> 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.
I don't think we should take "hard to implement" as an argument in this
discussion :)
Seems, whole Ignite peer class loading design need to be improved.
> 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.
This is common issue to every user-provided code.
Wrong implementation of affininty function is one the examples that comes in
the mind.
I think flexibility is good thing, so I'm -1 to reduce it.
What do you think?
В Пн, 05/08/2019 в 17:35 +0300, Pavel Kovalenko пишет:
> Nikolay,
>
> Thank you for your feedback.
> Could you please tell more about cases when custom node filter that not
> relies on node attributes may be used?
> For me, it's flexibility just for flexibility that introduces problems
> described in the topic.
> I don't see yet any practical cases with NodeFilter that can't be resolved
> using just labels.
>
>
>
> пн, 5 авг. 2019 г. в 16:28, Nikolay Izhikov :
>
> > Ivan,
> >
> > ~Mail~ Talks are cheap! Show me the code (C) :)
> >
> >
> > class NodeAttributeFilter implements IgnitePredicate {
> > private String name;
> > private T value;
> >
> >
> > public boolean apply(ClusterNode n) {
> > return Objects.equals(n.attribute(name), value);
> > }
> >
> > //...setters, getters.
> > }
> >
> >
> > В Пн, 05/08/2019 в 16:11 +0300, Павлухин Иван пишет:
> > > Hi Nikolay,
> > >
> > > Could you please elaborate how will NodeAttributeFilter behave? Do you
> > > mean specifying attribute name and value for exact comparison inside?
> > > Without any dynamic (user) code involved?
> > >
> > > Also I it is quite interesting for me what flexibility you are
> > > thinking about? I think that the topic is quite important and it would
> > > be great to collect use cases and describe best practices in
> > > documentation.
> > >
> > > пн, 5 авг. 2019 г. в 15:38, Nikolay Izhikov :
> > > >
> > > > Hello, Pavel.
> > > >
> > > > I think we shouldn't reduce flexibility of NodeFilter.
> > > > So, I am -1 to remove it in Ignite 3.
> > > >
> > > > Instead, Ignite can provide NodeAttributeFilter implementation of
> >
> > NodeFilter.
> > > > Seems, it will resolve all described issues.
> > > >
> > > >
> > > > В Чт, 01/08/2019 в 19:33 +0300, Ilya Kasnacheev пишет:
> > > > > 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,
> > >
> > >
> > >
signature.asc
Description: This is a digitally signed message part
Re: Replacing NodeFilter functionality with label approach
Nikolay,
Thank you for your feedback.
Could you please tell more about cases when custom node filter that not
relies on node attributes may be used?
For me, it's flexibility just for flexibility that introduces problems
described in the topic.
I don't see yet any practical cases with NodeFilter that can't be resolved
using just labels.
пн, 5 авг. 2019 г. в 16:28, Nikolay Izhikov :
> Ivan,
>
> ~Mail~ Talks are cheap! Show me the code (C) :)
>
>
> class NodeAttributeFilter implements IgnitePredicate {
> private String name;
> private T value;
>
>
> public boolean apply(ClusterNode n) {
> return Objects.equals(n.attribute(name), value);
> }
>
> //...setters, getters.
> }
>
>
> В Пн, 05/08/2019 в 16:11 +0300, Павлухин Иван пишет:
> > Hi Nikolay,
> >
> > Could you please elaborate how will NodeAttributeFilter behave? Do you
> > mean specifying attribute name and value for exact comparison inside?
> > Without any dynamic (user) code involved?
> >
> > Also I it is quite interesting for me what flexibility you are
> > thinking about? I think that the topic is quite important and it would
> > be great to collect use cases and describe best practices in
> > documentation.
> >
> > пн, 5 авг. 2019 г. в 15:38, Nikolay Izhikov :
> > >
> > > Hello, Pavel.
> > >
> > > I think we shouldn't reduce flexibility of NodeFilter.
> > > So, I am -1 to remove it in Ignite 3.
> > >
> > > Instead, Ignite can provide NodeAttributeFilter implementation of
> NodeFilter.
> > > Seems, it will resolve all described issues.
> > >
> > >
> > > В Чт, 01/08/2019 в 19:33 +0300, Ilya Kasnacheev пишет:
> > > > 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,
> >
> >
> >
>
Re: Replacing NodeFilter functionality with label approach
Ivan,
~Mail~ Talks are cheap! Show me the code (C) :)
class NodeAttributeFilter implements IgnitePredicate {
private String name;
private T value;
public boolean apply(ClusterNode n) {
return Objects.equals(n.attribute(name), value);
}
//...setters, getters.
}
В Пн, 05/08/2019 в 16:11 +0300, Павлухин Иван пишет:
> Hi Nikolay,
>
> Could you please elaborate how will NodeAttributeFilter behave? Do you
> mean specifying attribute name and value for exact comparison inside?
> Without any dynamic (user) code involved?
>
> Also I it is quite interesting for me what flexibility you are
> thinking about? I think that the topic is quite important and it would
> be great to collect use cases and describe best practices in
> documentation.
>
> пн, 5 авг. 2019 г. в 15:38, Nikolay Izhikov :
> >
> > Hello, Pavel.
> >
> > I think we shouldn't reduce flexibility of NodeFilter.
> > So, I am -1 to remove it in Ignite 3.
> >
> > Instead, Ignite can provide NodeAttributeFilter implementation of
> > NodeFilter.
> > Seems, it will resolve all described issues.
> >
> >
> > В Чт, 01/08/2019 в 19:33 +0300, Ilya Kasnacheev пишет:
> > > 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,
>
>
>
signature.asc
Description: This is a digitally signed message part
Re: Replacing NodeFilter functionality with label approach
Hi Nikolay, Could you please elaborate how will NodeAttributeFilter behave? Do you mean specifying attribute name and value for exact comparison inside? Without any dynamic (user) code involved? Also I it is quite interesting for me what flexibility you are thinking about? I think that the topic is quite important and it would be great to collect use cases and describe best practices in documentation. пн, 5 авг. 2019 г. в 15:38, Nikolay Izhikov : > > Hello, Pavel. > > I think we shouldn't reduce flexibility of NodeFilter. > So, I am -1 to remove it in Ignite 3. > > Instead, Ignite can provide NodeAttributeFilter implementation of NodeFilter. > Seems, it will resolve all described issues. > > > В Чт, 01/08/2019 в 19:33 +0300, Ilya Kasnacheev пишет: > > 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, -- Best regards, Ivan Pavlukhin
Re: Replacing NodeFilter functionality with label approach
Hello, Pavel. I think we shouldn't reduce flexibility of NodeFilter. So, I am -1 to remove it in Ignite 3. Instead, Ignite can provide NodeAttributeFilter implementation of NodeFilter. Seems, it will resolve all described issues. В Чт, 01/08/2019 в 19:33 +0300, Ilya Kasnacheev пишет: > 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, signature.asc Description: This is a digitally signed message part
Re: Replacing NodeFilter functionality with label approach
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 : > 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? >
