> > On 24.02.2017 г., at 17:38, Alex Heneveld <[email protected]> > wrote: > > 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.
Don't think I've ever seen overriding `/etc/hosts` with a resolvable hostname/IP. Makes sense though. Sounds like we should do this during deployment in Brooklyn, wdyt? Agree overriding the default behaviour should be possible, but hopefully should be needed rarely - that's the point of this discussion. > > Where it's being managed by another blueprint I like the use of > network-specific sensors. > I meant network specific values added to the node record. So that REST clients can use them, the same way entities would refer to the network-specific sensors. Svet. > On 24.02.2017 г., at 17:38, Alex Heneveld <[email protected]> > wrote: > > 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. >>>> >>> >> >>
