I provided technical objections, multiple times here and on the doc, based on the fact that you propose a major extension that will further complicate an already brittle configuration format, which multiple people are similarly and concurrently also trying to extend in incompatible ways. The validity of this objection is to be judged by other committers, and I believe that Michael's email above confirms that my concern is valid.
Others have raised questions / concerns about the need for the feature, and its interaction with multiple other features, which was not described in the design doc. Regarding the release - three committers have responded that this should not go to 3.4, and that it is unlikely to get in 3.5 since it is a major change and will contribute to destabilizing the release. Good luck, Alex On Tue, Nov 13, 2018 at 11:44 PM Ted Dunning <ted.dunn...@gmail.com> wrote: > The general rule at Apache is that if somebody has an itch to implement > something, they do it. > > I have a strong need for this feature and will be implementing it. Doing so > doesn't change what features get pushed. > > Regarding votes and such, commits are normally only subject to technical > blocks. Absent a valid technical objection to using an existing > configuration format, I plan to move forward with this. I am sympathetic to > a desire for a new config and will even contribute to that effort, but I > can't wait for it. > > On Tue, Nov 13, 2018, 22:25 Alexander Shraer <shra...@gmail.com wrote: > > > This seems like a good feature for ZooKeeper to eventually have, but I > > don't see why it must make 3.4 and 3.5 while other features are pushed > out > > to 3.6. > > Like any other feature, it would be subject to a vote and isn't a > > unilateral decision. > > > > On Tue, Nov 13, 2018 at 1:59 PM Ted Dunning <ted.dunn...@gmail.com> > wrote: > > > > > 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 <shra...@gmail.com> > > > 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 <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 > > > > > > > > > > > > > > >
