Fix backend ports to be seperated

[arenstar]

server webserver 10.0.0.10:8000,10.0.0.20:8001 check

Does not work using haproxy 1.4.24 on centos - it only checks the 8000 port

To fix this i modified the template to write the backend servers like

server webserver 10.0.0.10:8000 check
server webserver 10.0.0.20:8001 check

This is a simpler method which allows both ports to be checked

Cheers

[kitchen]

Now, I've never actually tried to specify multiple ports like that, but is there a semantic difference between doing this and having them both on the same 'server' line?

If there is, I think the existing behavior should be preserved. If you need a separate server line for each port, use multiple balancermember resources, one for each port, instead.

[arenstar]

@kitchen - please check the documentation associated with HaProxy.
I did alot of reading before making a fix and creating this ticket. I do believe that its not the correct way to do this. The loadbalance algorithm doesnt function correctly with this syntax

Please check for yourself - http://haproxy.1wt.eu/download/1.4/doc/configuration.txt
5. Server and default-server options

This configuration syntax cant be found by me....

[kitchen]

I agree, it feels weird to have one server with 2 ports, I just wasn't sure if there was a legit use case for it. I'll look in a bit!

-Jeremy

Insert PGP signature here.

On Jun 2, 2014, at 5:29 AM, arenstar notifications@github.com wrote:

@kitchen - please check the documentation associated with HaProxy.
I did alot of reading before making a fix and creating this ticket. I do believe that its not the correct way to do this. The loadbalance algorithm doesnt function correctly with this syntax

Please check for yourself - http://haproxy.1wt.eu/download/1.4/doc/configuration.txt
5. Server and default-server options

This configuration syntax cant be found by me....

—
Reply to this email directly or view it on GitHub.

[arenstar]

Well in my particular case, i create python backends based on the number of cores the machine has.
Which means that multiple ports are open per machine.
Haproxy effectively binds them together to create a "larger" backend - so i can begin to treat servers/nodes/machines as backends by obfuscating those internal ports.

I do believe this is a common use case, hence why i would love to see this merged :)

[kitchen]

no, I meant in haproxy config having multiple ports per server vs just multiple server lines.

if the former is a valid use case, then your use case should be simply to export multiple balancermembers, one for each port.

if the former is not a valid use case, then it would make sense to merge this!

[kitchen]

So, looking more at this: here and here, it looks like "server" takes a single address:port, so this PR is totally valid.

Looking at the 1.5 docs it looks roughly the same, so I'd say mergeit :)

[hunner]

After reading the docs for a while, I think the use case of a single binding port and multiple server/port combinations on the backend (whether used in haproxy::listen or haproxy::backend) is valid, and not checking each one is a problem. I am not an HAProxy expert and don't have a corpus of valid configs to go off of (which would be helpful) so I'll trust you on this.

@kitchen Do you use the frontend/backend entries too, or just the listen entries?

[kitchen]

I only use frontend/backend actually (I originally adapted the module to support them, previously it just had listen) but this is more a balancermember thing. The "server" line is standard, and as far as I can tell from the docs doesn't actually support multiple ip:ports on one server line. I don't even know what actually is supposed to happen if you put multiple ip:ports on the same server line, my guess would be a syntax error from haproxy but considering how long this has been here, probably not :)

[hunner]

@kitchen I am trying to sort out what parts are duplicated or awkward (such as trying to have a frontend that binds to :80 non-ssl and :443 ssl, which isn't currently possible). Do you have some example use cases you could share?

The apache::vhost has a parameter called custom_fragment which allows basically any configuration to be passed into a block... turns out writing valid vhosts is much easier in that case :). Do you think haproxy::frontend/backend/listen should get these too? Like #90

[kitchen]

I don't think it needs a custom_fragment, you can pass arbitrary settings to the options parameter and they end up in the config. That's not 100% perfect, but at least it makes good for compatibility. The reason it's not perfect is because it's hard to use hiera to manage the haproxy class's globals and defaults stanzas since it's pretty much all contained in the options param and hiera doesn't support merging (and you can't just defaults => hiera_hash() because puppet < 3). This isn't as big of a problem for the listen, frontend, and backend resources since you generally define them directly, but if you're using create_resources it can get tricky. I don't do any of that craziness though, I just have sane defaults across the board for globals and defaults (in my global.yaml) and then override things at the frontend/backend level.

As for the ssl bit I am using 1.4 so I don't have SSL support, but I would probably make those 2 separate frontends anyways. I think? Just like I do right now with apache ssl vs non-ssl.

[hunner]

Okay, sounds valid. Thanks for the feedback. I'll look at getting this PR rebased for merge.

[kitchen]

sorry to be a necromancer here, but I had a thought:

being able to specify configuration options to various stanzas as a resource would be awesome.

Let me give you an example:

I use the role/profile pattern. I try to keep individual bits of functionality as separate classes and include them as necessary. One of these bits of functionality we've come up with as of late is a go service which implements rate limiting for API requests. We implement this by dropping in a frontend for the proxy to proxy back to (which just defaults to using the 'normal' backend that the original frontend would), a backend which just has the rate limiting proxy (which currently just runs on localhost, but that may change) configured, an acl to match requests by, and a use_backend with the acl to send requests at it.

I have this all implemented as a separate class, but since my "main" haproxy::frontend for the overall service lives in a different profile, I have to manage the acl and such there, thus breaking compartmentalization. Also, I have ACLs for another service we're proxying to via this haproxy, and it would be awesome to be able to break that all out into its own class as well.

On top of that, since I'm not quite ready for it to go into production yet, I've got this set up as a feature toggle in my puppet code (toggled via a hiera key) and I have lots of nested array concats to build up the final acl and use_backend lists... it's frustrating :)

I realize that is hella confusing, and if you'd like I can draw up either some puppet code, or a sample haproxy config file (or both) to illustrate.

The obvious thing would be to just have an haproxy::acl and haproxy::use_backend resource and those wrap concat::fragments which you target like haproxy::balancermember resources, but then we're breaking the beauty of how generic the existing haproxy::* resources work. So maybe like an haproxy::config_part or something resource which just takes an options => array like the existing haproxy::* resources and injects them into the target stanza.

This would make it possible to do what I was mentioning above, as I would just inject the acl and use_backends into the "main" frontend stanza from my profile, and then when I want to enable that functionality I just include the class. This also means the feature toggle can just be a class param on the class which actually implements the feature, making things even cleaner.

As I said, I can draw up a use case, and probably even a sample implementation if you'd like.