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 авг.
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
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
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
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
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
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
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
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);
}
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
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!
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
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
13 matches
Mail list logo
