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? 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. Thanks, Shawn
