Re: Plea for eyes (and votes) on STATUS proposals
On Jan 23, 2013, at 1:00 PM, Daniel Ruggeri drugg...@primary.net wrote: On 1/23/2013 11:30 AM, Jim Jagielski wrote: iirc, there were people who did not like that :) Do you mean PPI in *addition to* BI? Yes Fine w/ me... do people agree?
Re: Plea for eyes (and votes) on STATUS proposals
On Jan 22, 2013, at 8:49 PM, Daniel Ruggeri drugg...@primary.net wrote: As usual, mileage varies. I didn't test the case of a proxypass at server level with a balancer there as well... here is my config: BalancerInherit Off Proxy balancer://mycluster BalancerMember https://127.0.0.1:4433 route=1 /Proxy ProxyPass /proxy/ balancer://mycluster/ Listen 192.168.0.103:80 VirtualHost 192.168.0.103:80 ... ProxyPass /proxy2/ balancer://mycluster/ /VirtualHost Attempts to hit /proxy/ on that vhost work every time (with BalancerInherit Off). Attempts to hit /proxy2/ return a 503 and AH01171: balancer://mycluster: No workers in balancer. I'd say that the former is definitely unexpected but the latter is fairly reasonable. There was a ProxyPassInherit as part of the original patch... maybe that needs to be revisited? iirc, there were people who did not like that :) Do you mean PPI in *addition to* BI?
Re: Plea for eyes (and votes) on STATUS proposals
On 1/23/2013 11:30 AM, Jim Jagielski wrote: iirc, there were people who did not like that :) Do you mean PPI in *addition to* BI? Yes - I always believe in giving the admin the control to decide the what's and how... The case of ProxyPass at server level (regardless of a balancer in play or not) is enough to have ProxyPassInherit as a companion to BalancerInherit. Regarding the first statement, (maybe I read the conversation wrong) I don't think Graham's concerns were an outright objection to the idea. I think he asked for the same stuff I mentioned in the STATUS file - just better documentation to understand what does/does not get changed as a result of disabling these directives and the inconsistencies that could occur when enabled. I'm sure it goes without saying, but I will anyway. To avoid very confused server admins, it's important that these default to On and preserve the way things have always been (this is what has been proposed, after all). -- Daniel Ruggeri
Re: Plea for eyes (and votes) on STATUS proposals
On Jan 21, 2013, at 4:09 PM, Rainer Jung rainer.j...@kippdata.de wrote: On 21.01.2013 15:26, Jim Jagielski wrote: Disabling BalancerInherit is only needed when using the Balancer Manager and only if there are conflicts between a Balancer in the top-level server and a vhost. With BI On, if a balancer is defined at the top level, then vhosts A and B get their own individual copy. But when using the Balancer Manager, it may be difficult or impossible to affect change in the balancer you want. If you use BM to change the Balancer of the top-level server, those changes do not get applied to the vhosts that had inherited them when httpd was 1st started. This can be confusing. Understood and agreed. Having BI Off ensures that: 1. All Balancers must be explicitly defined for whatever vhosts are using them 2. All changes on those Balancers affect ONLY that specific server. I find it hard to really understand what's going on after applying the patch. Many configuration items are still inherited even with BI Off, but the underlying balancers and/or workers are no longer inherited. Examples are ProxyPass or Proxy. I am unsure what kind of behavior this could lead to. For example I tested: What's important is to recall that it's just the Balancers and Workers which are affected. Nothing else. Thats the reason for the directive name-change, to make it clear that it only affects those 2 components. You would have noticed that if you had used ProxyPass /p/ http://myvhost:8080/ then even with BI Off, it would have worked in the vhost case. Again, the balancer is defined in the top level server but it's not inherited. Also note that BI *only* is of interest if people do silly things like define all their Balancers at the top level and use them only in Vhosts. If they do reasonable things, like define all Proxy-related stuff in the vhosts where they should apply, then it doesn't matter if BI is off or on. BI exists only for edge-cases, and that's why it defaults to the existing behavior; but in some, you want to be able to disable that inheritance.
Re: Plea for eyes (and votes) on STATUS proposals
On 1/21/2013 3:09 PM, Rainer Jung wrote: I find it hard to really understand what's going on after applying the patch. Many configuration items are still inherited even with BI Off, but the underlying balancers and/or workers are no longer inherited. Examples are ProxyPass or Proxy. I am unsure what kind of behavior this could lead to. For example I tested: ProxyPass /p/ balancer://myvhost:8080/ Proxy balancer://myvhost:8080/ BalancerMember http://myvhost:8080/ /Proxy BalancerInherit Off VirtualHost *:8080 DocumentRoot htdocs/myvhost ServerName myvhost ErrorLog logs/myvhost-error_log CustomLog logs/myvhost-access_log common /VirtualHost As usual, mileage varies. I didn't test the case of a proxypass at server level with a balancer there as well... here is my config: BalancerInherit Off Proxy balancer://mycluster BalancerMember https://127.0.0.1:4433 route=1 /Proxy ProxyPass /proxy/ balancer://mycluster/ Listen 192.168.0.103:80 VirtualHost 192.168.0.103:80 ... ProxyPass /proxy2/ balancer://mycluster/ /VirtualHost Attempts to hit /proxy/ on that vhost work every time (with BalancerInherit Off). Attempts to hit /proxy2/ return a 503 and AH01171: balancer://mycluster: No workers in balancer. I'd say that the former is definitely unexpected but the latter is fairly reasonable. There was a ProxyPassInherit as part of the original patch... maybe that needs to be revisited? -- Daniel Ruggeri
Re: Plea for eyes (and votes) on STATUS proposals
On Jan 20, 2013, at 3:56 PM, Daniel Ruggeri drugg...@primary.net wrote: On 1/17/2013 6:52 AM, Jim Jagielski wrote: *ping* :) (yeah, I am kinda pushing/hoping for the balancer stuff to be in 2.4.4 in time for ACNA13) BalancerPersist: Tested fine and works as expected (+1) Side note A lot of folks look at the configuration file as the canonical source for how the server is configured. With dynamic changes persisted, aspects of the configuration can be incorrect. Seems like a lot of work, but it may be worth considering a patch to WARN if the conf vs restored configs differ. I think we can do a simple log when we are persisting... BalancerInherit: Bug https://issues.apache.org/bugzilla/show_bug.cgi?id=52402 hampers testing of BalancerInherit On case. Bug notes imply that current 2.4 branch should have a fix for balancer at server level with many vhosts, but no one really calls out which commit should fix it so I can confirm. Tested with current 2.4.x branch w/ proxypassinherit.patch only... Before giving a vote, I'd like to be able to confirm that balancers at the server level work again. What patch is needed for this? Disabling BalancerInherit is only needed when using the Balancer Manager and only if there are conflicts between a Balancer in the top-level server and a vhost. With BI On, if a balancer is defined at the top level, then vhosts A and B get their own individual copy. But when using the Balancer Manager, it may be difficult or impossible to affect change in the balancer you want. If you use BM to change the Balancer of the top-level server, those changes do not get applied to the vhosts that had inherited them when httpd was 1st started. This can be confusing. Having BI Off ensures that: 1. All Balancers must be explicitly defined for whatever vhosts are using them 2. All changes on those Balancers affect ONLY that specific server.
Re: Plea for eyes (and votes) on STATUS proposals
On 1/21/2013 8:26 AM, Jim Jagielski wrote: Disabling BalancerInherit is only needed when using the Balancer Manager and only if there are conflicts between a Balancer in the top-level server and a vhost. With BI On, if a balancer is defined at the top level, then vhosts A and B get their own individual copy. But when using the Balancer Manager, it may be difficult or impossible to affect change in the balancer you want. If you use BM to change the Balancer of the top-level server, those changes do not get applied to the vhosts that had inherited them when httpd was 1st started. This can be confusing. Having BI Off ensures that: 1. All Balancers must be explicitly defined for whatever vhosts are using them 2. All changes on those Balancers affect ONLY that specific server. Understood - but with the bug noted earlier, isn't it impossible to have a balancer at the server level make its way into vhosts any more because of [Mon Jan 21 12:06:06.432596 2013] [proxy_balancer:debug] [pid 22337:tid 3075496144] mod_proxy_balancer.c(816): AH01184: Doing workers create: balancer://mycluster (s5aac9634_mycluster), 480, 2 [Mon Jan 21 12:06:06.432605 2013] [slotmem_shm:debug] [pid 22337:tid 3075496144] mod_slotmem_shm.c(632): AH02293: slotmem(/usr/local/apache/logs/experimental/slotmem-shm-s5aac9634_mycluster.shm) grab failed. Num 2/num_free 0 [Mon Jan 21 12:06:06.432612 2013] [proxy_balancer:emerg] [pid 22337:tid 3075496144] (22)Invalid argument: AH01186: worker slotmem_grab failed [Mon Jan 21 12:06:06.432637 2013] [:emerg] [pid 22337:tid 3075496144] AH00020: Configuration Failed, exiting This error happens any time one creates a balancer at server level and it attempts pushing it down to the vhosts. If I add the BalancerInherit patch, there is no change until 'BalancerInherit Off'. With it disabled, at least it starts but of course, none of the vhosts have that balancer anymore. So the patch itself seems to work, yes. I was hoping to draw more attention to the issue of not being able to define balancers at the server level anymore, though. IMHO, that's a much bigger problem. So is that bug supposed to be fixed, or do we roll 2.4.4 without this functionality? I guess it's technically not a regression if it's always been broken. -- Daniel Ruggeri
Re: Plea for eyes (and votes) on STATUS proposals
On 21.01.2013 15:26, Jim Jagielski wrote: Disabling BalancerInherit is only needed when using the Balancer Manager and only if there are conflicts between a Balancer in the top-level server and a vhost. With BI On, if a balancer is defined at the top level, then vhosts A and B get their own individual copy. But when using the Balancer Manager, it may be difficult or impossible to affect change in the balancer you want. If you use BM to change the Balancer of the top-level server, those changes do not get applied to the vhosts that had inherited them when httpd was 1st started. This can be confusing. Understood and agreed. Having BI Off ensures that: 1. All Balancers must be explicitly defined for whatever vhosts are using them 2. All changes on those Balancers affect ONLY that specific server. I find it hard to really understand what's going on after applying the patch. Many configuration items are still inherited even with BI Off, but the underlying balancers and/or workers are no longer inherited. Examples are ProxyPass or Proxy. I am unsure what kind of behavior this could lead to. For example I tested: ProxyPass /p/ balancer://myvhost:8080/ Proxy balancer://myvhost:8080/ BalancerMember http://myvhost:8080/ /Proxy BalancerInherit Off VirtualHost *:8080 DocumentRoot htdocs/myvhost ServerName myvhost ErrorLog logs/myvhost-error_log CustomLog logs/myvhost-access_log common /VirtualHost In this case the ProxyPass rule is inherited from the global server to the VHost myvhost. When I access curl -D - http://myvhost:8080/p/ I get a status 500 error page. VHost error log contains: mod_proxy_balancer.c(73): canonicalising URL //loghost:8080/ proxy_util.c(1849): *: found reverse proxy worker for balancer://loghost/ mod_proxy.c(1081): AH01143: Running scheme balancer handler (attempt 0) mod_proxy_http.c(2173): AH01113: HTTP: declining URL balancer://loghost/ AH01144: No protocol handler was valid for the URL /p/. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule. It is unexpected that the rule gets inherited but the worker needed by the rule not. I understand the reservations of Graham about breaking configs, but i think the proposed implementation is harder to understand. I don't have a solution, but I don't feel comfortable with the current inherit proposal either. I'm very open for comments! Regards, Rainer
Re: Plea for eyes (and votes) on STATUS proposals
On 1/17/2013 6:52 AM, Jim Jagielski wrote: *ping* :) (yeah, I am kinda pushing/hoping for the balancer stuff to be in 2.4.4 in time for ACNA13) BalancerPersist: Tested fine and works as expected (+1) Side note A lot of folks look at the configuration file as the canonical source for how the server is configured. With dynamic changes persisted, aspects of the configuration can be incorrect. Seems like a lot of work, but it may be worth considering a patch to WARN if the conf vs restored configs differ. BalancerInherit: Bug https://issues.apache.org/bugzilla/show_bug.cgi?id=52402 hampers testing of BalancerInherit On case. Bug notes imply that current 2.4 branch should have a fix for balancer at server level with many vhosts, but no one really calls out which commit should fix it so I can confirm. Tested with current 2.4.x branch w/ proxypassinherit.patch only... Before giving a vote, I'd like to be able to confirm that balancers at the server level work again. What patch is needed for this? Small note: This seemed to have no effect on ProxyPass statement inheritance from server level to vhosts when BalancerInherit was set to Off. Docs seems to imply that it controls ProxyPass workers just the same. Maybe docs just need to be more clear? Instead of ProxyPassed balancers/workers maybe say BalancerMember? Also, I think there should be more info about the noted inconsistencies for server-defined balancers/proxypass statements. A good example would be that the persist patch would not work on server-defined balancers if changes are made in the vhost. Other than that, I'm not sure what other inconsistencies and problems would be expected so it's probably worth warning server admins in docs. -- Daniel Ruggeri
Re: Plea for eyes (and votes) on STATUS proposals
On 1/17/2013 6:52 AM, Jim Jagielski wrote: *ping* :) (yeah, I am kinda pushing/hoping for the balancer stuff to be in 2.4.4 in time for ACNA13) *pong* :) I'm hoping to review those last two on Monday. Been trying for two weeks to get to them! -- Daniel Ruggeri
Re: Plea for eyes (and votes) on STATUS proposals
*ping* :) (yeah, I am kinda pushing/hoping for the balancer stuff to be in 2.4.4 in time for ACNA13) On Jan 11, 2013, at 10:27 AM, Jim Jagielski j...@jagunet.com wrote: I think we are quite close to a 2.4.4 release, with just a handful of open proposals in STATUS. If people could review, test and vote, that would be great.
Plea for eyes (and votes) on STATUS proposals
I think we are quite close to a 2.4.4 release, with just a handful of open proposals in STATUS. If people could review, test and vote, that would be great.
Re: Plea for eyes (and votes) on STATUS proposals
On 11.01.2013 16:27, Jim Jagielski wrote: I think we are quite close to a 2.4.4 release, with just a handful of open proposals in STATUS. If people could review, test and vote, that would be great. I can do something on Sunday. At least vote in the balancer proposals. Regards, Rainer
