From dev-return-75798-archive-asf-public=cust-asf.ponee.io@zookeeper.apache.org Tue Nov 13 17:15:27 2018 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 [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 9039B18062B for ; Tue, 13 Nov 2018 17:15:26 +0100 (CET) Received: (qmail 35856 invoked by uid 500); 13 Nov 2018 16:15:25 -0000 Mailing-List: contact dev-help@zookeeper.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@zookeeper.apache.org Delivered-To: mailing list dev@zookeeper.apache.org Received: (qmail 35843 invoked by uid 99); 13 Nov 2018 16:15:24 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Nov 2018 16:15:24 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 51834C23A8 for ; Tue, 13 Nov 2018 16:15:24 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=6.31 tests=[DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id QG-ZN0i4zvii for ; Tue, 13 Nov 2018 16:15:22 +0000 (UTC) Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 7649B5F536 for ; Tue, 13 Nov 2018 16:15:22 +0000 (UTC) Received: by mail-wm1-f51.google.com with SMTP id f2-v6so11954888wme.3 for ; Tue, 13 Nov 2018 08:15:22 -0800 (PST) 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=eHb48SCiZzDv1sUBRwzhhuEouLIZtLlDcSxcsNLXK4w=; b=VLJ6YCz2gb4CuS6CYIBt0plGrkCS1JFBgyL3LWSrY2/rWA7Ar2T4dyipjveRcGoze5 Yp+ZhrJCTdnuGqNmUiH9AvRzpALfzwZ33aWhi2iPBwy/rjOjkycVGbPRtfFbbrb51sJ9 DIlzo7khDmgPQMnv8yIzhMp0e3D+QrdJkK7lyhGJ04T4i6THXawHy2/Z/BTCHBNqgHhJ vj4STPzq3zZ0o0rjniQdFay4tXyU9mCNB1Z6himONfMLDayK3lA9vswChIOgkGBfAXSl WN5TREqh14ETFV2bQtlDJb85c+K9TWNnY1thkPkddmhJUXL8ywvi4VfTmkhG1yv2Ns9c Oj6w== 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=eHb48SCiZzDv1sUBRwzhhuEouLIZtLlDcSxcsNLXK4w=; b=g/rW0jTOHRwBFhRsfOCo1nImI5H6tJ6OPa3DAIbNq86vzrLe5uawoa8uGz7FmZ71ix f7rLCi7ovUm5IZTSztkPGBqlqZUBDlpXJbcOo294j7elrAF27SRl5IaaKuWc360ReGlv icSHAriVqn6fJ14mCGvUnabXzL2FfL2ZRWVZVUBWuLUszStgQVzoT+K4G1uSOqwOgFvL Zf5OomQzBE8VJ5XrvuHRlyda3yX6Nxl6HohEmMaRLFEl5yEgxUaq0iREfWX0Du5CxkzP zkqfwB0OHfkzFr58WWGCY24QaPGWWMrgIoA+PjNmaTsFozry5WFC4/13vsVn+7S5SPvo pRRw== X-Gm-Message-State: AGRZ1gJd9499RHUp3DeHtSFqFH9IQqpjQBaEH+bTHR1/ibRZ8t1Wrx/I 1Ci+4nCKU4Bl5ETFaSxaf5gty9Io42A1Vh6GdUjqg86s X-Google-Smtp-Source: AJdET5c2ufOuD/VuQFeCFzV+Jqjmr6AJ1kMvZW6iAhBiOgMtrEcafxABhtW900/g6odHSPmTGRVKt1meoYRN84dnP6M= X-Received: by 2002:a1c:568b:: with SMTP id k133-v6mr3997159wmb.4.1542125721559; Tue, 13 Nov 2018 08:15:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Enrico Olivelli Date: Tue, 13 Nov 2018 17:15:08 +0100 Message-ID: Subject: Re: question about approach to take To: DevZooKeeper Content-Type: text/plain; charset="UTF-8" Il giorno mar 13 nov 2018 alle ore 16:47 Alexander Shraer ha scritto: > > I also wanted to get other's views on this. > > My opinion is that the current server configuration format > (server.x=ip:port:port:role;ip:port) has run its course. There are multiple > proposals for additions/changes to the server configuration, > that would be simplified from having a more extensible format, such as a > json blob, as proposed by Brian Nixon here: > https://issues.apache.org/jira/browse/ZOOKEEPER-3166 > It is true that such an extension hasn't happened yet, however it may not > be a good idea to continue adding individual features to the existing > format instead of making this change. > > For longer than a year, maybe more, I've seen features pushed out to 3.6 to > avoid destabilizing the 3.5 release. If we follow the same logic here, this > would be a 3.6 feature, so compatibility with the old format doesn't seem > very important. > > What do others think ? Thank you Ted and Alexander for working on this important topic, I am following your work. Alexander "so compatibility with the old format doesn't seem very important" btw we must support compatibility, upgrade path from 3.5 must be as smooth as possible my 2c Enrico > > > Thanks, > Alex > > > > On Mon, Nov 12, 2018 at 11:47 PM Ted Dunning wrote: > > > There is a JIRA live for the network resilience feature that I mentioned > > previously. > > > > The design document > > < > > https://docs.google.com/document/d/1iGVwxeHp57qogwfdodCh9b32P2_kOQaJZ2GDo7j36fI/edit?usp=sharing > > > > > (also > > copied into the JIRA) has essentially converged except for two points. > > > > These include: > > > > 1) Artem Chernatsky has pointed out an opportunity to factor our port sets > > in the configuration syntax as well as an interesting interaction with the > > existing behavior where the current servers already listen to the specified > > ports on all NICs. This semantics of this interaction between configuration > > options need to be specified rigorously, but this doesn't appear to impact > > code complexity much, nor introduce any real difficulties. > > > > 2) Alex Shraer seems to feel that there is a strong interaction between > > this > > issue and a > > proposed > > refactorization of the configuration file syntax (mentioned in a comment in > > 3166, but apparently doesn't have an independent issue). In particular, he > > seems to think that the syntax refactorization is a blocker for the network > > resilience. My own feeling is that there is some interaction, but there is > > no strong ordering between the two issues if the implementors of this issue > > are willing to commit to supporting any consensus syntax change that is > > adopted. Essentially, there can be an additional issue filed which is > > blocked by both the syntax change issue and 3188 (network resilience) to > > support any new syntax. The work for 3188 needs to support the old syntax > > in any case so that we can backport changes to 3.4. > > > > Other open issues that are affected by configuration syntax change include > > 2534 , 2531 > > , 195 > > , and 2225 > > . None of these has > > any serious impact other than the fact that configuration needs to be > > abstracted as part of any change. Some appear to be quite old and may have > > already been solved or made moot. > > > > My own feeling is that pushing for this issue (3188) to include a change to > > the configuration syntax as well as the core network resilience feature > > proposed is an unacceptable increase in scope. I have filed a new tracking > > issue (3189) > > capturing the intended rework after a change in configuration syntax, but I > > can't find anywhere that the configuration change is captured in a issue to > > add the dependency. > > > > I also see no particular way that configuration syntax change (as desirable > > as it might be) blocks this feature. > > > > I would love to hear other opinions. > > > > > > I, myself, think that the "support resilience under new syntax when > > available" approach > >