On Tue, Apr 24, 2012 at 12:21 PM, Willy Tarreau <w...@1wt.eu> wrote: > Hi David, > > On Tue, Apr 24, 2012 at 11:46:52AM -0700, David Birdsong wrote: > > i'm not seeing my response that swear i sent last night... > > I swear I didn't see it :-)
so strange, gmail doesn't even have a saved draft to recall from. > > yes, this would solve our issues and would be very, very useful. > > OK, I'll have to think about it. Now I remember what the hard part > was, an ACL is a list of possible expressions, and each expression > supports multiple pattern sources. On the socket we could only reload > one pattern source of one type at a time, of course. So the complexity > comes in naming what we want to reload. For instance : > > acl bad_guys src 0.0.0.0/8 127.0.0.0/8 224.0.0.0/3 > acl bad_guys hdr_ip(x-forwarded-for) 0.0.0.0/8 127.0.0.0/8 > 224.0.0.0/3 > acl bad_guys hdr_ip(x-forwarded-for) -f manual.lst -f automatic.lst > > Now when trying to reload the "bad_guys" ACL, in fact we'd like to reload > one > of the files. Probably that we should find a way to name a specific > expression > (one ACL statement) that will have to be reloaded, I don't know. Or maybe > in a > first time we could reject reload requests for ACLs that have more than one > statement. > wow, yeah this could get tough to implement without adding some sort of name or keyword which i'm sure is a deal-breaker for backwards compatibility reasons. would the operations be read/update/insert or read/replace? the latter might be easier to implement; we(the user) could be asked to supply the filename exactly as it was named in the configuration which would then be followed the new data(replace). i admit this is makes it an odd case where haproxy config on disk doesn't match the running state; where a restart would revert back to values found on disk--but perhaps haproxy has already gone down that road with weights being set'able over the socket and in the config file. I also remember that some pattern parsing errors were sent to stderr and > will > have to be disabled when fed this way. In summary, nothing terribly complex > but nothing trivial either. > is that because stderr is long gone after haproxy has deamonized? could you send parsing errors to syslog? have you ever considered implementing a ring buffer to log the way that varnish logs? it's easy to solve the 'never block on disk' problem by putting the buffer file in a tmpfs, and it would provide a place to send errors for these odd corner cases. i'm mostly thinking aloud here. i really do love that haproxy never touches the filesystem after it's up and running. Regards, > Willy > >
