brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <alex.henev...@cloudsoftcorp.com>
Subject Re: [BROOKLYN-436] - Thoughts on making the URL an HA member is available at available
Date Fri, 24 Feb 2017 15:38:26 GMT
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 <
svetoslav.neykov@cloudsoftcorp.com> 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.
> >>
> >
>
>

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