On Mon, Dec 16, 2013 at 07:32:24PM -0500, Chris Burroughs wrote:
> On 12/04/2013 11:24 AM, Chris Burroughs wrote:
> >On 12/03/2013 04:07 PM, Chris Burroughs wrote:
> >>This could just be me not being adept at email patches. Sorry if this
> >>is obvious but is this supposed to apply against 1.4 or 1.5?
> >
> >To answer my own question this applies against 1.5. I'm not sure of the
> >feasibility or desirability of backporting to 1.4.
> >
> >I ran with this in a production load test and as far I can tell it
> >worked as advertised. We were able to run with nbproc and still have
> >useful looking stats sockets for haptop, ganglia etc. At least in our
> >use case, stats sockets with this patch solve the primary objection to
> >running with nbproc.
>
>
> Happpy to test additional patches or variants if further review is
> needed. Is there anything blockng this getting accepted into 1.5?
This changes the current behaviour as it prevents you from having for
example a TCP and a Unix socket. The proper way to do it is to have a
bind-process mask on the socket lines themselves.
I tried this in last january, I have a branch with some dead code
experimentation for this. The problem I faced was related to the
longest dependency chain :
peers -> tracked backend -> tracking backend -> frontend -> bind.
I found that the initial method I used consisting in having the frontend
impose its process-bind mask to the listeners was wrong and that it
should work the other way around :
- use the process-bind in the frontend as a default mask for the
"bind" lines
- have the process-bind keyword on the bind lines enforce the exact
value
- have the frontend finally bound to the same processes as its "bind"
lines
- force the backends to be bound at least to all processes the
frontends that connect to them are bound to
- recursively force the backends to be bound at least to all
processes the backends that track them are bound to
- push the backends masks to their peers
- reject configs where peers are bound to multiple processes
The global socket setting is the easiest thing to deal with in practice,
but doing it correctly has impacts everywhere unfortunately.
I experimented with a different method as above, which consists in just
"anding" masks between listeners, frontends, backends, etc... But this
results in configs that are hard to understand because you believe some
elements run on some processes but they don't due to another element
depending on them. For example, some people declare some backends which
are only used for health checks and which are tracked, and that no
frontend uses. You don't want these backends to run everywhere nor
do you want them not to be started.
I remember a few remaining cases such as when some ACLs reference a
backend or a frontend (eg: feconn() or beconn()), as well as when a
track-sc rule references a backend. Here again, it should automatically
push the mask to the associated backend.
In order to do this without changing the current behaviour, we'd have
the process-bind socket keyword default to the frontend's which defaults
to "all". This will result in propagating it everywhere. We'll also need
to have the backends be bound to at least their bind-process values.
Now the question is : could we start something at minima for the global
section and the stats socket without impacting the rest ?
I think so. Right now, the global section includes a hidden frontend
named "GLOBAL". It's bound to all processes. There's the
"stats bind-process" statement which allows you to change the "bind-process"
keyword of this frontend, it does exactly the same as the "bind-process"
keyword in other frontends.
So if add a "process" keyword on the "stats socket" and "bind" lines,
we could proceed this way :
- frontend defaults to ALL, and may be changed using "bind-process"
- listeners have a mask which defaults to zero (unset) and which may
be overridden using "process <list>".
- after parsing, all listeners which don't have a mask set inherit
the frontend's mask (for coherency)
- at the end, the frontend's mask is replaced with an OR of all of
its listeners' masks
This will allow us to stay compatible with what we currently have, and
to automatically compute the frontend's mask from its listeners.
For the stats sockets, it would mean that simply adding "process X" on
each "stats socket" line will be enough to map these sockets to their
own processes.
If someone is interested in working on this before -final, that would
be great. This would leave the door open for further improvements later.
Willy
