Feature Request: move listen (pool) port to the virtual server config tab entry

[adam65535]

In the loadbalancer (relayd) configuration it would be great to reuse pools for multiple virtual servers.  I have a couple groups of servers that host different services but contain the same list of servers.  Currently you can not reuse the same pool for multiple services because the listen port is defined with the pool.

The config files get generated so that pools only specify the servers and not the port.  The listen and forward port are put into the raw config file in the redirect item so there is no technical reason that the listen port would be defined in the pool.

This is the way things are generated now where you have to define two different pools.

table <serverpool1>{ 10.1.1.1, 10.1.1.2 }
table <serverpool2>{ 10.1.1.1, 10.1.1.2 }
redirect "VirtualServer1" {
  listen on 20.1.1.1 port 80
  forward to <serverpool1>port 80 check tcp
}
redirect "VirtualServer2" {
  listen on 20.1.1.1 port 443
  forward to <serverpool2>port 443 check tcp
}

This is what could be generated if pools only specified the servers and not the port:

table <serverpool1>{ 10.1.1.1, 10.1.1.2 }
redirect "VirtualServer1" {
  listen on 20.1.1.1 port 80
  forward to <serverpool1>port 80 check tcp
}
redirect "VirtualServer2" {
  listen on 20.1.1.1 port 443
  forward to <serverpool1>port 443 check tcp
}

If the pool just specified the servers and not the listen port and the virtual server defined the listen port and forward port I could make use of the same pool specification for multiple virtual servers.  This would reduce the amount of gui work to setup multiple services on the same group of servers.

Is there some other reason pools are associated with ports that I am not aware of?  It just seems like how it was implemented and not a technical reason to associate the port with the pool.

I realize nobody will have time to implement this as I am sure there are more important things to work on but it would be a nice thing to keep in mind for the future.  Less work to do the same thing is a sure win for people using a lot of load balancer entries.</serverpool1></serverpool1></serverpool1></serverpool2></serverpool1></serverpool2></serverpool1>

[jimp]

That would remove functionality that people require now. The port for the VS and the port for the pool are separate. They do not have to be the same. The VS can listen on one port and the actual servers in the pool can listen on another, for example a VS on port 80 but the pool servers are on port 8080 running unprivileged. Moving that to an additional setting on the VS might work, but introduces other issues on upgrade or otherwise accommodating existing configurations that need to use separate ports.

[adam65535]

The ports could still be different.  You would just specify both ports separately into the Virtual Server definition instead of one in the pool and one in the virtual server entry.  This would allow the two ports to be different and still be able to reuse tables (pools).

Upgrading script would require looking up the pool associated with the virtual server and pull in the port that was specified for the pool and put it into the newly added port specification on the virtual server.  There will be 2 ports specified on the virtual server entry now.  The only issue to the upgrade script would be what to do if someone has a pool defined but does not have a virtual server defined yet for it.  Since there would be no association to put the pool port into a virtual server you would just not use the port specified anymore.  That is really not a complication though and more of a realizing that both ports or now specified in the virtual server entry.

This configuration matches the way the relayd actually gets configured in the config file and allows for pool reuse for other virtual servers.

[jimp]

As the saying goes: Patches accepted.

I don't see anyone here going through the trouble, but if the code shows up…