followed
> > by restart of a single server are ignored. It is necessary to stop all
> > servers and do the steps above to make any changes to the ensemble.
> >
> > Thanks,
> >
> > Alexander Shraer wrote on 06/23/2017 01:20:47 AM:
> >
> > > From: Al
On Fri, Jun 23, 2017 at 6:09 AM, Shawn Heisey 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 w
ensemble.
>
> Thanks,
>
> Alexander Shraer wrote on 06/23/2017 01:20:47 AM:
>
> > From: Alexander Shraer
> > To: user@zookeeper.apache.org
> > Date: 06/23/2017 01:21 AM
> > Subject: Re: How to add nodes to a Zookeeper 3.5.3-beta ensemble
> > with recon
M:
> From: "Guillermo Vega-Toro"
> To: user@zookeeper.apache.org
> Date: 06/23/2017 09:18 AM
> Subject: Re: How to add nodes to a Zookeeper 3.5.3-beta ensemble
> with reconfigEnabled=false
>
> Thanks all for looking at this.
>
> Here is what I've found to make
On Thu, Jun 22, 2017 at 11:20 PM, Alexander Shraer
wrote:
> I'm not sure it's necessary for backward compatibility since rolling
> restarts for config changes are not really an api the system provides.
>
Yeah, it is not part of API in a strict sense but there are tools /
management software buil
01:21 AM
> Subject: Re: How to add nodes to a Zookeeper 3.5.3-beta ensemble
> with reconfigEnabled=false
>
> I'm not sure it's necessary for backward compatibility since rolling
> restarts for config changes are not really an api the system provides.
>
> I&#x
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 shou
I'm not sure it's necessary for backward compatibility since rolling
restarts for config changes are not really an api the system provides.
I'd think the ACL control and admin only API should be sufficient for
security and would prefer to get rid of the flag. But if you must have it,
we have to pr
Hi Alex, thanks for clarification!
It makes sense to me that users should use reconfig instead of rolling
upgrade moving forward. The only concern is backward compatibility now we
drop the old rolling upgrade support: since 3.5.x needs to be backward
compatible with 3.4.x [1], I think we probably
Hi Michael,
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
reconfigEnabled only disables reconfig command when reconfigEnabled=false;
it does not disable the feature by mute all code paths of the reconfig
feature introduced in ZOOKEEPER-107. So regardless of the value of
reconfigEnabled,
3.5.x ZK will create static config file and dynamic config file in an
This sounds like a bug in the implementation of reconfigEnabled.
Could you please open a JIRA with the description you provided ?
Out of curiosity, why do you disable reconfig ? It is intended exactly
to perform the changes you're trying to make, in a simple and correct way.
Thanks,
Alex
On Thu,
I'm still unable to make configuration changes when reconfigEnabled=false
by updating zoo.cfg and restarting the servers.
For example, I want to change the weight of one of my servers. I edit
zoo.cfg on the server I want to change, and specify the group, server.x,
and weight.x properties for al
You can still do rolling restarts for 3.5.x including 3.5.3-beta. Rolling
restart requires edits the zoo.cfg - the static configuration files,
instead of zoo.cfg.dynamic.x, which is the dynamic reconfiguration file
that stores reconfig parameters. This dynamic config file is managed by ZK
and is no
Hi,
I have a 3-node Zookeeper 3.5.3-beta ensemble. This was initially created
by un-taring the Zookeeper tarball into 3 machines, editing the zoo.cfg
file with the 3 server entries, and starting the servers. The ensemble
started, and a zoo.cfg.dynamic.1 file was created with the
server
15 matches
Mail list logo
