Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
From: Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
Subject: Re: [BROOKLYN-436] - Thoughts on making the URL an HA member is
 available at available
To: dev@brooklyn.apache.org
References: <56835424-B600-4133-9A06-17F9357309CB@cloudsoftcorp.com>
Message-ID: <b1f3fe3d-4811-0caa-7739-2064148af10e@CloudsoftCorp.com>
Date: Fri, 24 Feb 2017 13:45:35 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
 Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <56835424-B600-4133-9A06-17F9357309CB@cloudsoftcorp.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
archived-at: Fri, 24 Feb 2017 13:45:54 -0000


Svet-

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.)

--A


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: https://issues.apache.org/jira/browse/BROOKLYN-436
>
> 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 instead?
>
> 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 "0.0.0.0"
>    * 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 protocol)
>
> 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.
>