You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Svetoslav Neykov <sv...@cloudsoftcorp.com> on 2017/02/24 12:19:45 UTC
[BROOKLYN-436] - Thoughts on making the URL an HA member is available
at available
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.
Re: [BROOKLYN-436] - Thoughts on making the URL an HA member is
available at available
Posted by Svetoslav Neykov <sv...@cloudsoftcorp.com>.
>
> On 24.02.2017 г., at 17:38, Alex Heneveld <al...@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 <al...@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.
>>>>
>>>
>>
>>
Re: [BROOKLYN-436] - Thoughts on making the URL an HA member is
available at available
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
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.
> >>
> >
>
>
Re: [BROOKLYN-436] - Thoughts on making the URL an HA member is
available at available
Posted by Svetoslav Neykov <sv...@cloudsoftcorp.com>.
> 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 <al...@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.
>>
>
Re: [BROOKLYN-436] - Thoughts on making the URL an HA member is
available at available
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
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.
>