zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shraer <shra...@gmail.com>
Subject Re: question about approach to take
Date Tue, 13 Nov 2018 15:46:42 GMT
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:
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 ?


On Mon, Nov 12, 2018 at 11:47 PM Ted Dunning <ted.dunning@gmail.com> 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 <https://issues.apache.org/jira/browse/ZOOKEEPER-3188> 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 <https://issues.apache.org/jira/browse/ZOOKEEPER-2534>, 2531
> <https://issues.apache.org/jira/browse/ZOOKEEPER-2531>, 195
> <https://issues.apache.org/jira/browse/ZOOKEEPER-195>, and 2225
> <https://issues.apache.org/jira/browse/ZOOKEEPER-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 <https://issues.apache.org/jira/browse/ZOOKEEPER-3189> (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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message