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 16:37:28 GMT
> 
> On 24.02.2017 г., at 17:38, Alex Heneveld <alex.heneveld@cloudsoftcorp.com> 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 <alex.heneveld@cloudsoftcorp.com> 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 <
> 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
View raw message