-
Story
-
Resolution: Unresolved
-
Minor
-
None
There are cases where a Jenkins instance can be accessible through different network interfaces.
When using a reverse proxy, the jnlp host and ports advertised can be overridden through system properties, e.g. hudson.TcpSlaveAgentListener.hostName and hudson.TcpSlaveAgentListener.port. These get exposed as HTTP headers as X-Jenkins-JNLP-Host and X-Jenkins-JNLP-Port to JNLP agents during handshake.
Unfortunately at the moment only one hostname can be exposed through these headers. This is fine when all agents you connect belong to the same network and access the master through a unique network interface, but when you have some agents connecting from an internal network, and some others through an external network, some of them won't be able to connect on the advertised host name.
In some environments where split DNS are available (e.g. AWS), this problem is mitigated since a single dns name can be resolved differently based on where the source is located (within the same VPC, it would resolve to a private address, outside, it would resolve to the public address).
But this is not the case everywhere and sometimes you are stuck using ips.
The idea behind this story would be to allow advertising multiple hostnames, and then the remoting client would try them in order until the connection succeeds.