zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Han <h...@cloudera.com>
Subject Re: How to add nodes to a Zookeeper 3.5.3-beta ensemble with reconfigEnabled=false
Date Fri, 23 Jun 2017 16:24:38 GMT
On Fri, Jun 23, 2017 at 6:09 AM, Shawn Heisey <apache@elyograg.org> wrote:

> On 6/22/2017 11:39 PM, Alexander Shraer wrote:
> > The described behavior is the intended one - in 3.5 configuration is
> > part of the synced state and is updated when the server syncs with the
> > leader. The only rolling upgrade I tested was to upgrade the software
> > version of the servers - this should still work. But I didn't try to
> > support rolling upgrade for upgrading the configuration, since this
> > should be done through reconfig.
>
> If the intent is to get rid of the old way of changing the configuration
> (update zoo.cfg and perform rolling restarts) and only support dynamic
> reconfiguration, then why is there a reconfigEnabled setting at all, and
> why does it default to false?


I don't think the intention is to completely deprecated the rolling
restarts in favor of reconfig - at least for 3.5.x releases. There was no
record on JIRA / apache email about the decision on deprecating rolling
restart as far as I can tell. I think the issue is that we are not very
well aware of this problem until OP brought this up.


> Based on everything that has been said here, it sounds like when
> reconfigEnabled is left alone or explicitly set it to false, the ability
> to change the ensemble configuration is entirely lost, because the
> server will pull the dynamic config from the ensemble on startup and any
> changes made to zoo.cfg are ignored.
>

This is correct.


>
> Thanks,
> Shawn
>
>


-- 
Cheers
Michael.

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