On Fri, Jun 23, 2017 at 6:09 AM, Shawn Heisey <[email protected]> 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.
