I am going to push this feature out sooner rather than later. That isn't a question. I and my team are going to do the work. Others are very welcome to help and I am sure that there will be high value in getting reviews from a wide group.
But we are already working on the code. And we will be pushing a version into both 3.4 and 3.5. I think that 3.6-ish is a great target for an improved configuration syntax. Better configuration is a great goal, but it isn't OK to delay other work. On Tue, Nov 13, 2018 at 3:47 PM Alexander Shraer <[email protected]> wrote: > 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 <[email protected]> > 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 > > >
