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 ? Thanks, Alex On Mon, Nov 12, 2018 at 11:47 PM Ted Dunning <ted.dunn...@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 >
