brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <>
Subject Re: [BROOKLYN-436] - Thoughts on making the URL an HA member is available at available
Date Fri, 24 Feb 2017 13:45:35 GMT


Why not just encourage people to use "publicAddress" and/or make sure 
the hostname is set sensibly ?

Feels like any heuristic we use (whether hostname, most public 
locally-known IP or externally reported address) will be imperfect.  
Local hostname feels like the best strategy which is what your flowchart 
makes it sound like we do -- although you then say it's the "local 
address".  (I'd be in favour of switching to the former if we're doing 
the latter so that the advice above works.)


On 24/02/2017 12:19, Svetoslav Neykov wrote:
> Summary of the issue: Each HA member node publishes a URL it's available at in the persisted
state. For the Karaf build no value is set.
> Available at:
> When fixing the issue I'm wondering whether we should stick to the existing behaviour
for inferring the URL or change it a bit. TL;DR - should we use the public IP of the machines
> Current steps for building the URL are:
>    * Get the hostname from "--publicAddress" command line option if set
>    * Get the hostname from "--bindAddress" command line option if set and not ""
>    * Get the hostname of the local machine (can be overriden in config with "brooklyn.location.localhost.address"
system property)
>    * Combine the above with the port the web server is configured to run at (and the
> The default behaviour from above is to set the URL to the local address of the machine.
> There are a couple of common uses of the value:
>    1) Clients using the REST API will use it to find what's the MASTER of the cluster
by going to any member.
>    2) Users going to a non-master web UI will be offered the option to be redirected
to the MASTER
> 1) Could need either the public or the private IP, depending on where the HA members
are relative to the client using them.
> 2) Most often need the public URL, but sometimes the local address might be preferred
- for example when connecting by VPN to the member's network.
> By public IP here I mean what IP the machine is visible to the world with. The machine
might not have a public IP assigned at all, and be NATted to the internet instead.
> Another use case could be to use the hostname from the URL to let the MASTER  configure
networking access for the standby servers.
> Given the above I don't think a one size fits all solution is possible. I think we should
keep the existing URL using the local address and provide a second value with the public URL
as well. This will let clients pick the one (they think) is appropriate.
> Svet.

View raw message