From dev-return-46864-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Mon Aug 5 15:33:48 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 8BE06180181 for ; Mon, 5 Aug 2019 17:33:48 +0200 (CEST) Received: (qmail 3630 invoked by uid 500); 5 Aug 2019 15:33:47 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 3615 invoked by uid 99); 5 Aug 2019 15:33:47 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Aug 2019 15:33:47 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 257F11802F5 for ; Mon, 5 Aug 2019 15:33:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.8 X-Spam-Level: * X-Spam-Status: No, score=1.8 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-he-de.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id F91pmkdrbRUW for ; Mon, 5 Aug 2019 15:33:45 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::244; helo=mail-lj1-x244.google.com; envelope-from=jokserfn@gmail.com; receiver= Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id 6A2B07D3FB for ; Mon, 5 Aug 2019 15:33:44 +0000 (UTC) Received: by mail-lj1-x244.google.com with SMTP id i21so409041ljj.3 for ; Mon, 05 Aug 2019 08:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Bdp7wb8yGifPN9b8fZ6YYpLOgDytBxDY8B25FDee5Y0=; b=vW9eMCnq4w/U0AldkI+okAao4eLzgm4y+HHoiI8m6Ew1TAhkWd0UyogfcXn9X/coes umAjBAO5+hveoXzbYp+ACn5mc7ErQh/O8FpQae3AoyJqlJDL7KBDCbEKlcuNPgT/TXhK hM2NJnSYWRLC43xqe9zHMOw7KHzIDi6Y2HFQ2R/NQh2jRPZDcb1dEZFUnVHLqe0Jo2SY PqgygrJBt9yDaFr13vlgw4qtQL+NfcqARql7X8rI7VH/aYWKNC0tYzk9Qn0ZoMyprE62 4agos7fgVYX/zAHG5y817s3sccOZCdJwnJmfQV51sLfGCBVUEP7uaf568CUqVzmWpg4D v2Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Bdp7wb8yGifPN9b8fZ6YYpLOgDytBxDY8B25FDee5Y0=; b=BCpl3PDFR9EXpro6OVsaXq5XADJJ07ZBwS6qToHt0OjPdmm/ThMEdvhqeEwVfwCa3W 7UZYeQF5gpOLRyuLL8xk3fpEzLD0PNi3WLwR0rRC0juiUx8fOH/JRBOTVHeOWmZs3ctj QTOOd925KAx0vNKJLNf2ApDYG1G1Bpr4O/auWlAKFrAUffb7BEfAYGl7KG/YGONXZkvy daiOllkyIe/yffPDiQRy/P+E9HCHj15SpzEgvubd9YJMniB0pwR4M7XwBArY6oqND1P8 ZaSylCe2gJpK41hhVCDD74qXPSJuX+m2eqdLfmmxKzqduqbEowB7jXE0J6kFroi0oXPC FOsg== X-Gm-Message-State: APjAAAUldF0qfyDnOJHwuJSMFUY0+kxjvXHExG0FiHTszI8T2It1/tJY 8VSoh+nc7Kloz3xEXgdbdpHHTbuUcAsRV7h3x+wX68l0 X-Google-Smtp-Source: APXvYqw3MN7KEKx3ULpzbbrL4A2BnpctZn182ueL9jquPO+YsVEI7VBwQtuUbIcal+PsvxjngIVKGvlJYkLe8t5q1jI= X-Received: by 2002:a2e:3a13:: with SMTP id h19mr61844301lja.220.1565019223578; Mon, 05 Aug 2019 08:33:43 -0700 (PDT) MIME-Version: 1.0 References: <4b1bd8443f336c3d634869504f0e1dbfb77d0283.camel@gmail.com> <6c1fe12f3bd5394b35edf28b977c4c5d9d24487a.camel@gmail.com> In-Reply-To: <6c1fe12f3bd5394b35edf28b977c4c5d9d24487a.camel@gmail.com> From: Pavel Kovalenko Date: Mon, 5 Aug 2019 18:33:32 +0300 Message-ID: Subject: Re: Replacing NodeFilter functionality with label approach To: dev@ignite.apache.org Content-Type: multipart/alternative; boundary="000000000000e3603d058f606e75" --000000000000e3603d058f606e75 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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? =D0=BF=D0=BD, 5 =D0=B0=D0=B2=D0=B3. 2019 =D0=B3. =D0=B2 17:56, Nikolay Izhi= kov : > 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 wheth= er > > or nor they required on them. This increases the complexity of resolvin= g > > 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 for= ce > > users to properly implement .equals() method on NodeFilter class. We ca= n > > 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? > > =D0=92 =D0=9F=D0=BD, 05/08/2019 =D0=B2 17:35 +0300, Pavel Kovalenko =D0= =BF=D0=B8=D1=88=D0=B5=D1=82: > > 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. > > > > > > > > =D0=BF=D0=BD, 5 =D0=B0=D0=B2=D0=B3. 2019 =D0=B3. =D0=B2 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. > > > } > > > > > > > > > =D0=92 =D0=9F=D0=BD, 05/08/2019 =D0=B2 16:11 +0300, =D0=9F=D0=B0=D0= =B2=D0=BB=D1=83=D1=85=D0=B8=D0=BD =D0=98=D0=B2=D0=B0=D0=BD =D0=BF=D0=B8=D1= =88=D0=B5=D1=82: > > > > Hi Nikolay, > > > > > > > > Could you please elaborate how will NodeAttributeFilter behave? Do > you > > > > mean specifying attribute name and value for exact comparison insid= e? > > > > 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. > > > > > > > > =D0=BF=D0=BD, 5 =D0=B0=D0=B2=D0=B3. 2019 =D0=B3. =D0=B2 15:38, Niko= lay 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. > > > > > > > > > > > > > > > =D0=92 =D0=A7=D1=82, 01/08/2019 =D0=B2 19:33 +0300, Ilya Kasnache= ev =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > > > > > 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, > > > > > > > > > > > > > --000000000000e3603d058f606e75--