zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: question about approach to take
Date Tue, 13 Nov 2018 21:58:30 GMT
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 <shralex@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.dunning@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message