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. > > We've had a long established policy of only making fixes in the fix releases, and as I've stated before we should stop making feature/improvement changes in 3.5 so that it can stabilize. Active development (e.g. the great patches from Alex and recently Fangmin and others) have been landing in trunk/master. If the community can reach consensus on the proposed changes it would make sense to me to include in 3.6 or later. Regards, Patrick > > 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 > > > > > >
