> 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 <[email protected]> > 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. >> >
