Well nevermind. Applying the namespace to the remote peers isn't quite as simple. The local peer was simple as it behaves like a normal frontend bind. But it appears the remote peers are treated rather differently, and don't share anything with the server struct, and thus can't as easily accept all the server options.
-Patrick On 2016/10/14 23:39, hapr...@stormcloud9.net wrote: > So I took a poke at this, and it seems pretty trivial to add an option > to support changing the namespace for a peer local binding. However I > implemented it on my own system by just copying the bind keyword > parsing code out of `cfg_parse_listen`. Meaning that I just added > support for *ALL* bind keywords, not just `namespace`. > > Given how trivial it was, I'm willing to attempt putting together a > patch to add the functionality, but have a few questions. > The primary question is should I add support for all bind options? Or > only the `namespace` option? > Should I do something similar for the peer remotes, adding support for > all server options? > > Other thoughts? > > -Patrick > > On 2016/10/9 21:59, Patrick Hemmer wrote: >> Can we get the ability to configure the peer namespace? >> Right now haproxy uses the default namespace, but in our system we >> have an "internal" interface which is able to talk to the other >> haproxy nodes, and this interface is in another network namespace. >> >> Additionally, the error output for failure to bind to a peer address >> is lacking. I had to do an `strace` to figure out what the error was: >> [ALERT] 282/214021 (2725) : [haproxy.main()] . >> [ALERT] 282/214021 (2725) : [haproxy.main()] Some protocols failed to >> start their listeners! Exiting. >> >> That's on haproxy 1.6.9 >> >> Anyway, I can change the namespace that haproxy is launched in, and >> then manually override the namespace for every `bind` and `server` >> parameter, but it's rather cumbersome to do so. Would be much nicer >> to be able to control the peer binding namespace, just like any other >> bind. >> >> If this would be a simple change, I might be willing to attempt it. >> But I've never worked in the haproxy source before, so not sure how >> involved it would be. >> >> Thanks >> >> -Patrick >
