mod_proxy hooks for clustering and load balancing

[Paul Querna <pa...@querna.org>]

Hi,

There is lots of discussion about fixing mod_proxy and
mod_proxy_balancer, to try to make it do things that the APIs are just
broken for, and right now, it seems from the outside to be turning
into a ball of mud.

I think the right way to frame the discussion is, how should the API
optimally be structured -- then change the existing one to be closer
to it, rather than the barrage of incremental changes that seem to be
creating lots of cruft, and ending up with something that still
doesn't do what we want.

I think mod_proxy's decisions on what to proxy to, and where, should
be designed as a series of hooks/providers, specifically:

1) Provider for a list of backends -- This provider does nothing with
balancing, just provides a list of Backend Definition (preferably just
keep it apr_sockaddr_t?) that a Connection is able to use.  -- Backend
status via multicast or other methods go here.
2) Provider that _sorts_ the list of backends.  Input is a list,
output is a new ordered list.  -- Sticky sesions go here, along with
any load based balancing.
3) Provider that given a Backend Definition, returns a connection.
(pools connections, or open new one, whatever)  -- Some of the
proxy_util and massive worker objects go here.

Using this structure, you can implement a dynamic load balancer
without having to modify the core.  I think the key is to _stop_
passing around the gigantic monolithic proxy_worker structures, and go
to having providers that do simple operations: get a list, sort the
list, get me a connection.

Thoughts?

Thanks,

Paul

Re: mod_proxy hooks for clustering and load balancing

[Rainer Jung <ra...@kippdata.de>]

On 06.05.2009 20:26, Paul Querna wrote:
> There is lots of discussion about fixing mod_proxy and
> mod_proxy_balancer, to try to make it do things that the APIs are just
> broken for, and right now, it seems from the outside to be turning
> into a ball of mud.
> 
> I think the right way to frame the discussion is, how should the API
> optimally be structured -- then change the existing one to be closer
> to it, rather than the barrage of incremental changes that seem to be
> creating lots of cruft, and ending up with something that still
> doesn't do what we want.
> 
> I think mod_proxy's decisions on what to proxy to, and where, should
> be designed as a series of hooks/providers, specifically:
> 
> 1) Provider for a list of backends -- This provider does nothing with
> balancing, just provides a list of Backend Definition (preferably just
> keep it apr_sockaddr_t?) that a Connection is able to use.  -- Backend
> status via multicast or other methods go here.
> 2) Provider that _sorts_ the list of backends.  Input is a list,
> output is a new ordered list.  -- Sticky sesions go here, along with
> any load based balancing.
> 3) Provider that given a Backend Definition, returns a connection.
> (pools connections, or open new one, whatever)  -- Some of the
> proxy_util and massive worker objects go here.
> 
> Using this structure, you can implement a dynamic load balancer
> without having to modify the core.  I think the key is to _stop_
> passing around the gigantic monolithic proxy_worker structures, and go
> to having providers that do simple operations: get a list, sort the
> list, get me a connection.
> 
> Thoughts?

Sounds good. The provider in 2) needs a second functionality/API to feed
back the results of a request:

- whether the backend was detected as being broken

- when using piggybacked load data or (as we do today) locally generated
load data the updates must be done against the provider 2) after the
response has been received (or in the case of busyness once before
forwarding the request and once after receiving the response)

Those providers look similar to what I called "topology manager" and
"state manager" and you want to include the balancing/stickyness
decision into the state manager. My remark above somehow indicates, that
the provider 2) needs to make the decision *and* to update the data ón
which the decision is based. This data update could happen behind the
scenes, but in most cases it will need an API to be driven by the
request handling component.

Regards,

Rainer

Re: mod_proxy hooks for clustering and load balancing

[Deputy Director General <dy...@myanmar.com.mm>]

Please stop your sending email to me.
Thank you.



----- Original Message ----- 
From: "jean-frederic clere" <jf...@gmail.com>
To: <de...@httpd.apache.org>
Sent: Thursday, May 07, 2009 5:20 PM
Subject: Re: mod_proxy hooks for clustering and load balancing


> Paul Querna wrote:
>> Hi,
>> 
>> There is lots of discussion about fixing mod_proxy and
>> mod_proxy_balancer, to try to make it do things that the APIs are just
>> broken for, and right now, it seems from the outside to be turning
>> into a ball of mud.
>> 
>> I think the right way to frame the discussion is, how should the API
>> optimally be structured -- then change the existing one to be closer
>> to it, rather than the barrage of incremental changes that seem to be
>> creating lots of cruft, and ending up with something that still
>> doesn't do what we want.
>> 
>> I think mod_proxy's decisions on what to proxy to, and where, should
>> be designed as a series of hooks/providers, specifically:
>> 
>> 1) Provider for a list of backends -- This provider does nothing with
>> balancing, just provides a list of Backend Definition (preferably just
>> keep it apr_sockaddr_t?) that a Connection is able to use.  -- Backend
>> status via multicast or other methods go here.
>> 2) Provider that _sorts_ the list of backends.  Input is a list,
>> output is a new ordered list.  -- Sticky sesions go here, along with
>> any load based balancing.
>> 3) Provider that given a Backend Definition, returns a connection.
>> (pools connections, or open new one, whatever)  -- Some of the
>> proxy_util and massive worker objects go here.
> 
> So we have to store the whatever in order to reuse it, no?
> How to we handle the removable of a backend? We need to query the first 
> provider from time to time and clean up our storage, no?
> 
> Cheers
> 
> Jean-Frederic
> 
>

Re: mod_proxy hooks for clustering and load balancing

[jean-frederic clere <jf...@gmail.com>]

Paul Querna wrote:
> On Thu, May 7, 2009 at 3:50 AM, jean-frederic clere <jf...@gmail.com> wrote:
>> Paul Querna wrote:
>>> Hi,
>>>
>>> There is lots of discussion about fixing mod_proxy and
>>> mod_proxy_balancer, to try to make it do things that the APIs are just
>>> broken for, and right now, it seems from the outside to be turning
>>> into a ball of mud.
>>>
>>> I think the right way to frame the discussion is, how should the API
>>> optimally be structured -- then change the existing one to be closer
>>> to it, rather than the barrage of incremental changes that seem to be
>>> creating lots of cruft, and ending up with something that still
>>> doesn't do what we want.
>>>
>>> I think mod_proxy's decisions on what to proxy to, and where, should
>>> be designed as a series of hooks/providers, specifically:
>>>
>>> 1) Provider for a list of backends -- This provider does nothing with
>>> balancing, just provides a list of Backend Definition (preferably just
>>> keep it apr_sockaddr_t?) that a Connection is able to use.  -- Backend
>>> status via multicast or other methods go here.
>>> 2) Provider that _sorts_ the list of backends.  Input is a list,
>>> output is a new ordered list.  -- Sticky sesions go here, along with
>>> any load based balancing.
>>> 3) Provider that given a Backend Definition, returns a connection.
>>> (pools connections, or open new one, whatever)  -- Some of the
>>> proxy_util and massive worker objects go here.
>> So we have to store the whatever in order to reuse it, no?
>> How to we handle the removable of a backend? We need to query the first
>> provider from time to time and clean up our storage, no?
> 
> No reason to, just have a timeout on the connection pooler, after
> awhile it drops to zero connections.
> 

Do you plan to use a reslist for that? - If yes you need something more 
to clean it : the timeout handling is called in apr_reslist_acquire() -

Cheers

Jean-Frederic

Re: mod_proxy hooks for clustering and load balancing

[Paul Querna <pa...@querna.org>]

On Thu, May 7, 2009 at 3:50 AM, jean-frederic clere <jf...@gmail.com> wrote:
> Paul Querna wrote:
>>
>> Hi,
>>
>> There is lots of discussion about fixing mod_proxy and
>> mod_proxy_balancer, to try to make it do things that the APIs are just
>> broken for, and right now, it seems from the outside to be turning
>> into a ball of mud.
>>
>> I think the right way to frame the discussion is, how should the API
>> optimally be structured -- then change the existing one to be closer
>> to it, rather than the barrage of incremental changes that seem to be
>> creating lots of cruft, and ending up with something that still
>> doesn't do what we want.
>>
>> I think mod_proxy's decisions on what to proxy to, and where, should
>> be designed as a series of hooks/providers, specifically:
>>
>> 1) Provider for a list of backends -- This provider does nothing with
>> balancing, just provides a list of Backend Definition (preferably just
>> keep it apr_sockaddr_t?) that a Connection is able to use.  -- Backend
>> status via multicast or other methods go here.
>> 2) Provider that _sorts_ the list of backends.  Input is a list,
>> output is a new ordered list.  -- Sticky sesions go here, along with
>> any load based balancing.
>> 3) Provider that given a Backend Definition, returns a connection.
>> (pools connections, or open new one, whatever)  -- Some of the
>> proxy_util and massive worker objects go here.
>
> So we have to store the whatever in order to reuse it, no?
> How to we handle the removable of a backend? We need to query the first
> provider from time to time and clean up our storage, no?

No reason to, just have a timeout on the connection pooler, after
awhile it drops to zero connections.

Re: mod_proxy hooks for clustering and load balancing

[jean-frederic clere <jf...@gmail.com>]

Paul Querna wrote:
> Hi,
> 
> There is lots of discussion about fixing mod_proxy and
> mod_proxy_balancer, to try to make it do things that the APIs are just
> broken for, and right now, it seems from the outside to be turning
> into a ball of mud.
> 
> I think the right way to frame the discussion is, how should the API
> optimally be structured -- then change the existing one to be closer
> to it, rather than the barrage of incremental changes that seem to be
> creating lots of cruft, and ending up with something that still
> doesn't do what we want.
> 
> I think mod_proxy's decisions on what to proxy to, and where, should
> be designed as a series of hooks/providers, specifically:
> 
> 1) Provider for a list of backends -- This provider does nothing with
> balancing, just provides a list of Backend Definition (preferably just
> keep it apr_sockaddr_t?) that a Connection is able to use.  -- Backend
> status via multicast or other methods go here.
> 2) Provider that _sorts_ the list of backends.  Input is a list,
> output is a new ordered list.  -- Sticky sesions go here, along with
> any load based balancing.
> 3) Provider that given a Backend Definition, returns a connection.
> (pools connections, or open new one, whatever)  -- Some of the
> proxy_util and massive worker objects go here.

So we have to store the whatever in order to reuse it, no?
How to we handle the removable of a backend? We need to query the first 
provider from time to time and clean up our storage, no?

Cheers

Jean-Frederic

Re: mod_proxy hooks for clustering and load balancing

[Graham Leggett <mi...@sharp.fm>]

Paul Querna wrote:

> Stop worrying about 2.2, and just focus on doing it right -- then ship
> 2.4 in 3-4 months imo, trunk really isn't that far off from being a
> decent 2.4, it just needs some cleanup in a few areas. It has already
> been 3.5 years since 2.2.0 came out, its time to move on in my
> opinion.

+1.

Regards,
Graham
--

Re: mod_proxy hooks for clustering and load balancing

[Paul Querna <pa...@querna.org>]

On Wed, May 6, 2009 at 12:04 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On May 6, 2009, at 2:53 PM, Paul Querna wrote:
>
>>
>> Stop worrying about 2.2, and just focus on doing it right -- then ship
>> 2.4 in 3-4 months imo, trunk really isn't that far off from being a
>> decent 2.4, it just needs some cleanup in a few areas. It has already
>> been 3.5 years since 2.2.0 came out, its time to move on in my
>> opinion.
>>
>
> I'll stop worrying about 2.2 when 2.4 comes closer to being a reality.
>
> Not saying that releasing 2.4 isn't worth it, but there have been stops and
> starts all along the way, and I think we need to be clear on what we
> expect 2.4 to be. Until then, we have no clear defining line on when
> 2.4 is "done."

it can be done today, just start cutting alpha releases :)

i'm pretty close to ENOTIME though, so if someone wants to step up and
start RMing alphas that would be very nice.......

Re: mod_proxy hooks for clustering and load balancing

[Ruediger Pluem <rp...@apache.org>]

On 05/06/2009 10:31 PM, Jim Jagielski wrote:
> 
> On May 6, 2009, at 4:20 PM, Graham Leggett wrote:
> 
>> Jim Jagielski wrote:
>>
>>> I'll stop worrying about 2.2 when 2.4 comes closer to being a reality.
>>>
>>> Not saying that releasing 2.4 isn't worth it, but there have been
>>> stops and
>>> starts all along the way, and I think we need to be clear on what we
>>> expect 2.4 to be. Until then, we have no clear defining line on when
>>> 2.4 is "done."
>>
>> Is there anything additional that we want v2.4 to do over and above what
>> it does now?
>>
> 
> Well, that's the question, isn't it? I can't align the idea
> of trunk being a candidate for 2.4 and trunk being a place for
> people to experiment...
> 
> What do we want 2.4 to be and do. And how.
> 
> Once we define (and agree) to that, we know how close (or far)
> trunk is. It sounds like we have some set that wants to break
> trunk apart and totally refactor a lot of it, and that's a big +1.
> It's also not a 3-4 month effort :) It also sounds like there
> are people who want 2.4 to be an upgrade to 2.2 as 2.2 was compared
> to 2.4, and a big +1 to that as well. But BOTH of these are using
> the exact same dev branch, and there's no general agreement on which
> we want... if you get my point ;)
> 
> If we branch off 2.4 right now from trunk, and say that this becomes
> our next main release, and the idea is to clean up what is there,
> and, for new experimental stuff, develop on trunk 1st and then
> backport to 2.4, I'll jump right on in, since it means code will
> be out and released and *used* sooner!

Again a full +1 to all this.

Regards

Rüdiger

Re: mod_proxy hooks for clustering and load balancing

[Rainer Jung <ra...@kippdata.de>]

On 06.05.2009 22:31, Jim Jagielski wrote:
> 
> On May 6, 2009, at 4:20 PM, Graham Leggett wrote:
> 
>> Jim Jagielski wrote:
>>
>>> I'll stop worrying about 2.2 when 2.4 comes closer to being a reality.
>>>
>>> Not saying that releasing 2.4 isn't worth it, but there have been
>>> stops and
>>> starts all along the way, and I think we need to be clear on what we
>>> expect 2.4 to be. Until then, we have no clear defining line on when
>>> 2.4 is "done."
>>
>> Is there anything additional that we want v2.4 to do over and above what
>> it does now?
>>
> 
> Well, that's the question, isn't it? I can't align the idea
> of trunk being a candidate for 2.4 and trunk being a place for
> people to experiment...
> 
> What do we want 2.4 to be and do. And how.
> 
> Once we define (and agree) to that, we know how close (or far)
> trunk is. It sounds like we have some set that wants to break
> trunk apart and totally refactor a lot of it, and that's a big +1.
> It's also not a 3-4 month effort :) It also sounds like there
> are people who want 2.4 to be an upgrade to 2.2 as 2.2 was compared
> to 2.4, and a big +1 to that as well. But BOTH of these are using
> the exact same dev branch, and there's no general agreement on which
> we want... if you get my point ;)
> 
> If we branch off 2.4 right now from trunk, and say that this becomes
> our next main release, and the idea is to clean up what is there,
> and, for new experimental stuff, develop on trunk 1st and then
> backport to 2.4, I'll jump right on in, since it means code will
> be out and released and *used* sooner!

I expect there is already enough interesting new material in trunk right
now and users will find it a valuable 2.4. So yes, focus should be on
getting this out of the door.

If any trunk experiments turn out to be ready before 2.4.0 and backport
is low risk, we can backport (also if they are compatible with 2.4.x we
can backport later than 2.4.0).

To be clear: the OP (new mod_proxy hooks) might not be compatible with
the momentary trunk (breaking configuration), so before branching, the
question would also be: does anyone want to do something important soon,
that he wants to be in 2.4 and will be incompatible API wise or
configuration wise with the momentary trunk.

Regards,

Rainer

Re: mod_proxy hooks for clustering and load balancing

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Graham Leggett wrote:
> Jim Jagielski wrote:
> 
>> Once we define (and agree) to that, we know how close (or far)
>> trunk is. It sounds like we have some set that wants to break
>> trunk apart and totally refactor a lot of it, and that's a big +1.
>> It's also not a 3-4 month effort :) It also sounds like there
>> are people who want 2.4 to be an upgrade to 2.2 as 2.2 was compared
>> to 2.4, and a big +1 to that as well. But BOTH of these are using
>> the exact same dev branch, and there's no general agreement on which
>> we want... if you get my point ;)

Understandable; when we have something suitable for consideration as an
alpha, it's time to fork.  If we have something in trunk that is clearly
not slated for the next version, then we must fork, rm, and tag.

Right now I'm not clear that anything in trunk is destined for svn rm
from the 2.4 branch.  E.g. the mod_proxy devs are just as keen as the
aaa <require > refactoring and core httpd devs to put their changes
out there in the public sphere, and see what happens.

But the moment we have anything that looks like a beta, there is going
to need to be a fork.  Do you intend that 2.3.x branch -> 2.4.x branch
to be C-T-R or R-T-C?

> I think the bit that divides these in two is APR v2.0.

APR v2.0 is irrelevant, IMHO.  It would be nice, but there is plenty of
work to do there, and since there are plenty of interfaces in need of
renaming and deprecation, out-of-sorts arg lists which can't decide if
apr_pool_t * is the first or last arg, by convention (yes, there was a
convention), and so on, I don't think we should 'wait' for apr 2.

If it beats httpd to release, great.  If not, oh well :)

Re: mod_proxy hooks for clustering and load balancing

[Graham Leggett <mi...@sharp.fm>]

Jim Jagielski wrote:

> Well, that's the question, isn't it? I can't align the idea
> of trunk being a candidate for 2.4 and trunk being a place for
> people to experiment...
> 
> What do we want 2.4 to be and do. And how.
> 
> Once we define (and agree) to that, we know how close (or far)
> trunk is. It sounds like we have some set that wants to break
> trunk apart and totally refactor a lot of it, and that's a big +1.
> It's also not a 3-4 month effort :) It also sounds like there
> are people who want 2.4 to be an upgrade to 2.2 as 2.2 was compared
> to 2.4, and a big +1 to that as well. But BOTH of these are using
> the exact same dev branch, and there's no general agreement on which
> we want... if you get my point ;)

I think the bit that divides these in two is APR v2.0.

People have begun refactoring APR to produce APR v2.0, and alongside
this will be a corresponding refactoring of httpd, that I think should
be httpd v3.0.

I think httpd v2.4 should be what we have now, against the latest APR v1
we have now, which is the APR v1.4 branch.

I think practically we should focus on getting httpd v2.4 out the door,
and make httpd ready for v3.0 to happen, against APR v2.0.

Regards,
Graham
--

Re: mod_proxy hooks for clustering and load balancing

[Nick Kew <ni...@webthing.com>]

On 6 May 2009, at 21:31, Jim Jagielski wrote:

>
> On May 6, 2009, at 4:20 PM, Graham Leggett wrote:
>
>> Jim Jagielski wrote:
>>
>>> I'll stop worrying about 2.2 when 2.4 comes closer to being a  
>>> reality.
>>>
>>> Not saying that releasing 2.4 isn't worth it, but there have been  
>>> stops and
>>> starts all along the way, and I think we need to be clear on what we
>>> expect 2.4 to be. Until then, we have no clear defining line on when
>>> 2.4 is "done."
>>
>> Is there anything additional that we want v2.4 to do over and  
>> above what
>> it does now?
>>
>
> Well, that's the question, isn't it? I can't align the idea
> of trunk being a candidate for 2.4 and trunk being a place for
> people to experiment...
>
> What do we want 2.4 to be and do. And how.

Draw a line under instability caused by feature creep?
Won't happen.  There's too much momentum behind clustering/ 
loadbalancing.

So aim to provide a clean API for new developments - Paul's
original proposal?  Makes sense if we're in a position to do it.
I don't think it'll cure instability once-and-for-all, but if it can
disentangle that which we have and can clearly anticipate NOW
then we should do it.  The last thing we want is to commit
*knowingly* to 2.4 as another generation of "muddling along".

> If we branch off 2.4 right now from trunk, and say that this becomes
> our next main release, and the idea is to clean up what is there,
> and, for new experimental stuff, develop on trunk 1st and then
> backport to 2.4, I'll jump right on in, since it means code will
> be out and released and *used* sooner!

How about fleshing out new-clean-API *before* branching?
Else work-to-date falls into a state of limbo, while 2.4 (by differing
from trunk) remains under the same instability-pressure as 2.2.

+1 to pquerna: CleanAPI
+1 to wrowe: leave 2.2 to do what it does as a stable release

That leaves the question: what amongst current-trunk looks,
stable and what is clearly experimental?  CleanAPI should
provide for both, so the latter can develop as clean modules
over the lifetime of 2.4 without causing instability.

Would Step 1 here be to list what trunk needs over and above
what 2.2 (cleanly) provides?

-- 
Nick Kew

Re: mod_proxy hooks for clustering and load balancing

[Jim Jagielski <ji...@jaguNET.com>]

On May 6, 2009, at 4:20 PM, Graham Leggett wrote:

> Jim Jagielski wrote:
>
>> I'll stop worrying about 2.2 when 2.4 comes closer to being a  
>> reality.
>>
>> Not saying that releasing 2.4 isn't worth it, but there have been  
>> stops and
>> starts all along the way, and I think we need to be clear on what we
>> expect 2.4 to be. Until then, we have no clear defining line on when
>> 2.4 is "done."
>
> Is there anything additional that we want v2.4 to do over and above  
> what
> it does now?
>

Well, that's the question, isn't it? I can't align the idea
of trunk being a candidate for 2.4 and trunk being a place for
people to experiment...

What do we want 2.4 to be and do. And how.

Once we define (and agree) to that, we know how close (or far)
trunk is. It sounds like we have some set that wants to break
trunk apart and totally refactor a lot of it, and that's a big +1.
It's also not a 3-4 month effort :) It also sounds like there
are people who want 2.4 to be an upgrade to 2.2 as 2.2 was compared
to 2.4, and a big +1 to that as well. But BOTH of these are using
the exact same dev branch, and there's no general agreement on which
we want... if you get my point ;)

If we branch off 2.4 right now from trunk, and say that this becomes
our next main release, and the idea is to clean up what is there,
and, for new experimental stuff, develop on trunk 1st and then
backport to 2.4, I'll jump right on in, since it means code will
be out and released and *used* sooner!

Re: mod_proxy hooks for clustering and load balancing

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Graham Leggett wrote:
> Jim Jagielski wrote:
> 
>> I'll stop worrying about 2.2 when 2.4 comes closer to being a reality.
>>
>> Not saying that releasing 2.4 isn't worth it, but there have been stops and
>> starts all along the way, and I think we need to be clear on what we
>> expect 2.4 to be. Until then, we have no clear defining line on when
>> 2.4 is "done."
> 
> Is there anything additional that we want v2.4 to do over and above what
> it does now?

Conversely, anything that isn't done correctly yet in v2.4 that must be
refactored, or anything that is done in v2.4 that we simply wouldn't want
to release with 2.4.0?

Re: mod_proxy hooks for clustering and load balancing

[Graham Leggett <mi...@sharp.fm>]

Jim Jagielski wrote:

> I'll stop worrying about 2.2 when 2.4 comes closer to being a reality.
> 
> Not saying that releasing 2.4 isn't worth it, but there have been stops and
> starts all along the way, and I think we need to be clear on what we
> expect 2.4 to be. Until then, we have no clear defining line on when
> 2.4 is "done."

Is there anything additional that we want v2.4 to do over and above what
it does now?

Regards,
Graham
--

Re: mod_proxy hooks for clustering and load balancing

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Jim Jagielski wrote:
> 
> I'll stop worrying about 2.2 when 2.4 comes closer to being a reality.
> 
> Not saying that releasing 2.4 isn't worth it, but there have been stops and
> starts all along the way, and I think we need to be clear on what we
> expect 2.4 to be. Until then, we have no clear defining line on when
> 2.4 is "done."

Nice of the mod_proxy pot calling the httpd kettle black :-)

Re: mod_proxy hooks for clustering and load balancing

[Jim Jagielski <ji...@jaguNET.com>]

On May 6, 2009, at 2:53 PM, Paul Querna wrote:

>
> Stop worrying about 2.2, and just focus on doing it right -- then ship
> 2.4 in 3-4 months imo, trunk really isn't that far off from being a
> decent 2.4, it just needs some cleanup in a few areas. It has already
> been 3.5 years since 2.2.0 came out, its time to move on in my
> opinion.
>

I'll stop worrying about 2.2 when 2.4 comes closer to being a reality.

Not saying that releasing 2.4 isn't worth it, but there have been  
stops and
starts all along the way, and I think we need to be clear on what we
expect 2.4 to be. Until then, we have no clear defining line on when
2.4 is "done."

Re: mod_proxy hooks for clustering and load balancing

[Ruediger Pluem <rp...@apache.org>]

On 05/06/2009 10:09 PM, Jim Jagielski wrote:
> 
> On May 6, 2009, at 3:32 PM, William A. Rowe, Jr. wrote:
> 
>>
>> We should experiment freely on trunk/ to come up with the right
>> solutions,
>> and also freely discard those solutions from the next release branch. 
>> But
>> we shouldn't throw changes willy nilly over to 2.2, but as Paul says,
>> let's
>> focus on making 2.4 "the best available version of Apache" with all of
>> the
>> new facilities that come with it.
>>
> 
> What new facilities? Are we moving to serf, for example?
> 
> It's for these reason that I suggested that before we start breaking
> trunk by adding stuff willy-nilly we branch off a 2.4 tree... If we
> would say "this is 2.4... clean it up and fix it" then we could get
> 2.4 out soon. Instead, we have trunk being both a experimental
> sandbox for new stuff and the *only* place these will see the light
> anytime soon is in backporting to 2.2.
> 
> If we are serious about 2.4, we branch now. trunk remains the dev branch
> and we clean-up the 2.4 branch and backport from trunk to 2.4...
> We cannot "experiment freely" on trunk and at the same time try
> to focus down a 2.4 release...
> 
> 

+1

Regards

Rüdiger

Re: mod_proxy hooks for clustering and load balancing

[jean-frederic clere <jf...@gmail.com>]

Jim Jagielski wrote:
> 
> On May 6, 2009, at 3:32 PM, William A. Rowe, Jr. wrote:
> 
>>
>> We should experiment freely on trunk/ to come up with the right 
>> solutions,
>> and also freely discard those solutions from the next release branch.  
>> But
>> we shouldn't throw changes willy nilly over to 2.2, but as Paul says, 
>> let's
>> focus on making 2.4 "the best available version of Apache" with all of 
>> the
>> new facilities that come with it.
>>
> 
> What new facilities? Are we moving to serf, for example?

Shouldn't serf just being one of the "3) Provider that given a Backend 
Definition, returns a connection.".

Cheers

Jean-Frederic

Re: mod_proxy hooks for clustering and load balancing

[Jim Jagielski <ji...@jaguNET.com>]

On May 6, 2009, at 3:32 PM, William A. Rowe, Jr. wrote:

>
> We should experiment freely on trunk/ to come up with the right  
> solutions,
> and also freely discard those solutions from the next release  
> branch.  But
> we shouldn't throw changes willy nilly over to 2.2, but as Paul  
> says, let's
> focus on making 2.4 "the best available version of Apache" with all  
> of the
> new facilities that come with it.
>

What new facilities? Are we moving to serf, for example?

It's for these reason that I suggested that before we start breaking
trunk by adding stuff willy-nilly we branch off a 2.4 tree... If we
would say "this is 2.4... clean it up and fix it" then we could get
2.4 out soon. Instead, we have trunk being both a experimental
sandbox for new stuff and the *only* place these will see the light
anytime soon is in backporting to 2.2.

If we are serious about 2.4, we branch now. trunk remains the dev branch
and we clean-up the 2.4 branch and backport from trunk to 2.4...
We cannot "experiment freely" on trunk and at the same time try
to focus down a 2.4 release...

Re: mod_proxy hooks for clustering and load balancing

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Paul Querna wrote:
> On Wed, May 6, 2009 at 11:46 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>
>> The incremental changes are just so we can keep 2.2's proxy somewhat
>> useful and flexible enough to survive until the next revamp.
> 
> Stop worrying about 2.2, and just focus on doing it right -- then ship
> 2.4 in 3-4 months imo, trunk really isn't that far off from being a
> decent 2.4, it just needs some cleanup in a few areas. It has already
> been 3.5 years since 2.2.0 came out, its time to move on in my
> opinion.

+1.  If there is a 2.2 /bug/ let's fix it.  If the mod_proxy crew wants to
offer a proof-of concept, 2.4 preview as its own download, terrific!  But
I'm quite -1 to fundamentally modifying the structure or feature set that
ships for 2.2-stable.  The recent history in 2.2 of de-stable-izing changes
to the released branch, and incomplete features, leaves me pretty frustrated
with the lack of review.

Before /not/ voting -1 to bringing in these major changes, I'd need to see
issues.apache.org seriously purged of its 95 incidents, many of them new and
most of them actively triaged by our users@ community and some dedicated
dev@s.  I'd need to see balancer /actually documented/ in a way that users
can read and that is partitioned by the module that is loaded.

We should experiment freely on trunk/ to come up with the right solutions,
and also freely discard those solutions from the next release branch.  But
we shouldn't throw changes willy nilly over to 2.2, but as Paul says, let's
focus on making 2.4 "the best available version of Apache" with all of the
new facilities that come with it.

What is especially scary is that the providers are still all using mod_proxy
for their entire config schema, for directives which make no sense to any
other proxy provider.  It would be great to see some serious cleanup, in
addition to all the enthusiasm to expand mod_proxy.

Re: mod_proxy hooks for clustering and load balancing

[Paul Querna <pa...@querna.org>]

On Wed, May 6, 2009 at 11:46 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>
> On May 6, 2009, at 2:26 PM, Paul Querna wrote:
>
>> Hi,
>>
>> I think the right way to frame the discussion is, how should the API
>> optimally be structured -- then change the existing one to be closer
>> to it, rather than the barrage of incremental changes that seem to be
>> creating lots of cruft, and ending up with something that still
>> doesn't do what we want.
>>
>> I think mod_proxy's decisions on what to proxy to, and where, should
>> be designed as a series of hooks/providers, specifically:
>>
>> 1) Provider for a list of backends -- This provider does nothing with
>> balancing, just provides a list of Backend Definition (preferably just
>> keep it apr_sockaddr_t?) that a Connection is able to use.  -- Backend
>> status via multicast or other methods go here.
>> 2) Provider that _sorts_ the list of backends.  Input is a list,
>> output is a new ordered list.  -- Sticky sesions go here, along with
>> any load based balancing.
>> 3) Provider that given a Backend Definition, returns a connection.
>> (pools connections, or open new one, whatever)  -- Some of the
>> proxy_util and massive worker objects go here.
>>
>
> I recall at one of the hackthons this being proposed and I
> think it's the right one... It's a clear separation of functions
> similar to the changes we've done in authn/authz, moving from
> monolithic to more structured and defined concerns.
>
> The incremental changes are just so we can keep 2.2's proxy somewhat
> useful and flexible enough to survive until the next revamp.

Stop worrying about 2.2, and just focus on doing it right -- then ship
2.4 in 3-4 months imo, trunk really isn't that far off from being a
decent 2.4, it just needs some cleanup in a few areas. It has already
been 3.5 years since 2.2.0 came out, its time to move on in my
opinion.

Re: mod_proxy hooks for clustering and load balancing

[Jim Jagielski <ji...@jaguNET.com>]

On May 6, 2009, at 2:26 PM, Paul Querna wrote:

> Hi,
>
> I think the right way to frame the discussion is, how should the API
> optimally be structured -- then change the existing one to be closer
> to it, rather than the barrage of incremental changes that seem to be
> creating lots of cruft, and ending up with something that still
> doesn't do what we want.
>
> I think mod_proxy's decisions on what to proxy to, and where, should
> be designed as a series of hooks/providers, specifically:
>
> 1) Provider for a list of backends -- This provider does nothing with
> balancing, just provides a list of Backend Definition (preferably just
> keep it apr_sockaddr_t?) that a Connection is able to use.  -- Backend
> status via multicast or other methods go here.
> 2) Provider that _sorts_ the list of backends.  Input is a list,
> output is a new ordered list.  -- Sticky sesions go here, along with
> any load based balancing.
> 3) Provider that given a Backend Definition, returns a connection.
> (pools connections, or open new one, whatever)  -- Some of the
> proxy_util and massive worker objects go here.
>

I recall at one of the hackthons this being proposed and I
think it's the right one... It's a clear separation of functions
similar to the changes we've done in authn/authz, moving from
monolithic to more structured and defined concerns.

The incremental changes are just so we can keep 2.2's proxy somewhat
useful and flexible enough to survive until the next revamp.

Re: mod_proxy hooks for clustering and load balancing

[Graham Leggett <mi...@sharp.fm>]

Paul Querna wrote:

> Using this structure, you can implement a dynamic load balancer
> without having to modify the core.  I think the key is to _stop_
> passing around the gigantic monolithic proxy_worker structures, and go
> to having providers that do simple operations: get a list, sort the
> list, get me a connection.
> 
> Thoughts?

+1 on all of it.

Regards,
Graham
--