> On Aug 25, 2015, at 2:15 PM, Yann Ylavic <ylavic....@gmail.com> wrote: > > On Tue, Aug 25, 2015 at 6:16 PM, Jim Jagielski <j...@jagunet.com> 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. >
That's right. Adding balancers via the manager is to-be-done. > 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. The current code tries to ensure that the read-in slotmem info is "correct" and consistent. If there is any mismatch then the slotmem is ignored, cleaned or removed. > 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). I have a feeling that using the growth space for config-file changes is ill-advised. > 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 ;) I think that keeping it the way it was is likely easier and better for when we close the loop in making balancer addition part of the manager. This change will either be dropped or modded, in which case it's likely best to revert to avoid unneeded deltas and potential weird code paths.
