On Sun, Feb 4, 2018 at 3:32 PM, Jim Jagielski <j...@jagunet.com> wrote: > > >> On Feb 2, 2018, at 8:05 PM, Yann Ylavic <ylavic....@gmail.com> wrote: >> >> That's a new directive too, very specialized (though it's your point). >> Wouldn't it end up being declined to other modules one day or the other? >> But mainly, rather than ignoring config changes, I think mod_proxy_lb >> should ignore non-changes. >> And it already knows how to do that provided the vhost's balancer id >> does not change unnecessarily... > > The main point is that modules are free to determine what they > consider a unique Vhost; they are free to make whatever assumptions > are required. Inevitably, it depends on the module and WHY it needs > to know if a Vhost is "unique" and that will vary. Some will be more > stringent, others more free. Creating a user land directive which is > basically for internal module use doesn't help at all.
I agree with that in general, can we agree that mod_proxy_lb wants a fixed server id on restart and that it'd rather create new SHMs solely based on its own configuration changes (i.e. lbmethod, # members, members' loadfactor/status/...)? This is clearly not what happens currently (besides maybe the number of members which could make the SHM's size change and cause a reset). > > The only issue is that *in this particular case* there is a > weird use case where the assumption on what makes a > Vhost unique doesn't match with what they want. One > option, of course, is to say "Well, you need to figure out > a way such that when you adjust the config file, the line > number doesn't change". For such an extremely rare edge > case, this seems a valid suggestion, rather than directly > jumping into code and adding fluff and cruft that 99.9999% > of httpd users will never want and see. I don't understand why you state it's a weird/edge case. Start httpd, add a blank line anywhere before the vhost which runs the balancer, gracefuly restart httpd and see how new SHMs are created for the new generation, losing all the previous state (load distribution, errors, stats...). IMHO the old and new generations should share and preserve the state here. > > For example, consider the above. You say "I think mod_proxy_lb > should ignore non-changes.". What do we do for the admin > who doesn't feel that way? Or that we want ServerUID to be > one thing for module foo and another for module bar? Isn't > it up to the *module* itself to determine what makes sense? > The module itself is (hopefully!! :) ) designed and architected > and "logic" with its own specific assumption and requirement > on what a unique UID needs to be. I would guess that 99.999% > of the time, any change to that would cause really weird behavior. If modules want to build this uid for their own use they can already do that (with whatever they find relevent in the server_rec). But if they want to reassociate their resources to the same vhost regardless of changes (irrelevent to them) done on restart, how would they without the help of the only who knows (the webmaster)? This is where any automatic thing can't please everyone. Of course this does not avoid the module to check that the configuration they care about is still compatible with the resources they want to reuse, and to do the proper action otherwise, but anything else is irrevelevent to them. For instance, for the mod_proxy_lb case, if you add a listening IP or a ServerAlias I don't see why the balancer should suddenly clear everything, or refuse to start, should it? Isn't it about backend connections only? A quick look at "mod_bmx_vhost.c" (mentioned in the other thread) shows that it uses "BMXVHostDBMFilename" to identify vhosts, i.e. by their dbm path. If you want a simple and targeted solution for mod_proxy_lb, just let the admin configure the SHM file path, that's the UID. Simple. Friendly? hmm. Prone to directives proliferation? sure. > > This just seems like a heavy-weight "fix" for an extremely > weird on one-off edge case which is more suitably handled > by, if an actual code change is really *required*, a small > targeted patch. Again, the ServerUID is not a fix from my POV, it's not targeted at mod_proxy_lb. And the mod_proxy_lb case is not weird, it's a bug which we should fix, with or without ServerUID. But I don't want to push ServerUid against all odds, let's forget about it and talk about an internal/autmatic "server uid" which uniquely identifies a vhost and can serve all users (no that weird) needs. What would it be for mod_proxy_lb since we are at it? :)
