brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Svetoslav Neykov <svetoslav.ney...@cloudsoftcorp.com>
Subject Re: [BROOKLYN-436] - Thoughts on making the URL an HA member is available at available
Date Fri, 24 Feb 2017 14:31:59 GMT
> Why not just encourage people to use "publicAddress"

Usually it's the consumer of the API that can decide which address to use - public or local.
Similar to the public & subnet sensor suffixes.
Imagine that the Brooklyn instance is managed (i.e. BrooklynNode) what do we set the "publicAddress"
to - feels like we need the same logic but at the manager, not as a default behaviour.

> make sure the hostname is set sensibly ?

By "hostname" in the steps I mean "Networking.getInetAddressWithFixedName(value).getHostname()".
And by default it's "Networking.getLocalHost().getHostname()".

> Feels like any heuristic we use (whether hostname, most public locally-known IP or externally
reported address) will be imperfect.

Agree.

> Local hostname feels like the best strategy which is what your flowchart makes it sound
like we do

I think resolving the hostname from other machines rearly works in practice. Only in Amazon?
If it did work, then agree it's the best approach.
That's the reason why I think we should use addresses only (maybe hostname just in Amazon)
and provide both local and external.

Svet.

> On 24.02.2017 г., at 15:45, Alex Heneveld <alex.heneveld@cloudsoftcorp.com> wrote:
> 
> 
> 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.
>> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message