zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shraer <shra...@gmail.com>
Subject Re: question about approach to take
Date Tue, 13 Nov 2018 22:25:30 GMT
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.dunning@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 <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