zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject question about approach to take
Date Tue, 13 Nov 2018 07:46:26 GMT
There is a JIRA live for the network resilience feature that I mentioned

The design document
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