On Tue, Aug 25, 2015 at 6:16 PM, Jim Jagielski <[email protected]> wrote: > I see that, but the assumption is that the reason why the size > would have changed is that someone edited the httpd.conf file and > added another balancer.
That's the only way to add a balancer AFAICT, the manager allows to add members to existing balancers only. If so, how is an admin supposed to add a new balancer? Stop than start (removing by hand the persistant file, in between, if the slot persisted)? Should we do this automatically on startup and restart when the size changes? How starting from a clean fresh slate (with new size?) would help remote configuration (via the manager)? > At that point, the more logical thing > would be to wipe the slate clean (as we do in other places > where certain values in the slotmem != what we expect)... > Also, as mentioned, we DO want to fail if the size isn't > the same, and the only way the size can be different is if > someone changed the file config. So the underlying assumption > behind the patch is invalid, imo. If the current code is already able to ignore other-than-size changes for the slots' management, this commit won't change that. It solely allows the free space in slots (growth margin) to be used by both the restart and the manager for balancer members, and by the restart only for balancers (the limit on adding balancers is postponed to the growth margin exhaustion, currently it fails from the very first add in the configuration file whereas no one will ever use the reserved space). Sharing the balancer members' slots' bgrowth space between the configuration file and the manager does not look bad to me either, this has to be taken into account (in bgrowth) by the admin from startup (and even from the very first startup with persisted slots), but the admin is supposed to know how much members are likely to be added in the configuration file and/or via the manager. If no one adds any balancer or member in the file (it fails today btw), httpd will still work as before. If httpd is started with persisted slots created by a previous version, with or without new balancers/members, it will also work (up to the growth margin with new additions). The only visible change from the manager will be less space available for new additions. But I don't want to insist on preserving this change, so I'll revert it if the above did not convince you ;)
