Haproxy: Add range iterator item variable for server-template and also general zero-padding converter

[mjf]

Please add range iterator item variable for the server-template directive so that it can be expanded
in the <fqdn>:<port> (see in the example below). Also new general zero-padding converter to pad
values with zeroes would be splendid for server-template (therefor I aggregated both things to one
feature request)...

zeropad(<width>)
  Performs a zero-padding of preceding expression to the given <width>.

  Example:
    server-template s 3 "svc-%[rng.iteritem,zeropad(3)].domain.tld:80" check

    # would be equivalent to:
    server s1 svc-001.domain.tld:80 check
    server s2 svc-002.domain.tld:80 check
    server s3 svc-003.domain.tld:80 check

Thanks for your excellent work on HA-Proxy!

[mjf]

Moved to the official HAProxy mailing-list.

[TimWolla]

Thread is here for the interested people finding this issue in the future: https://www.mail-archive.com/[email protected]/msg33139.html

[mjf]

@TimWolla re-opened for https://www.mail-archive.com/[email protected]/msg33140.html

[git001]

I like the idea especially when you combine it with resolvers like consul or coreDNS ( Kubernetes ).

[rbvto]

Any news regarding this feature request?

It would benefit my setup greatly.
Right now my infrastructure is organized in the usual fashion with a load balancer in front of a myriad of computer nodes, all sequentially labeled computeX.
For each compute node I have two DNS entries, one in the name of computeX.domain which identifies the compute node itself and one entry on the computes.domain master entry, which contains a list of all compute nodes available in that specific region.

My configuration right now looks like:
(...) server-template compute_ computes.domain:8080 resolvers dns_setup init-addr none (...)

While that setup certainly works the issue i have with it is that when haproxy scours the DNS provider for information, dns returns an unordered list of addresses which leads to compute_X not corresponding to computeX.domain which makes debugging a single server quite difficult (solved this by keeping a separate channel for errors which contains computeX.domain. and cross-referencing a server that is pumping out errors with a server which has a high number of 500 returns).

With this change my configuration would perfectly connect compute_X to its corresponding computeX.domain address.