A good practice is to set the hostname on the box to a name which resolves as widely as possible. This can be set to IP if desired -- that's why I think whatever is in `/etc/hosts` is the nicest default but I don't think it matters too much; it's easily, and maybe sometimes should be, set manually.
Where it's being managed by another blueprint I like the use of network-specific sensors. --A On 24 February 2017 at 14:31, Svetoslav Neykov < [email protected]> wrote: > > 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. > >> > > > >
