Allow binding to multiple addresses. #13954

rmuir · 2015-10-06T05:45:27Z

For consistency and simplicity this means that es.network.host/bind_host/publish_host can all take arrays.

Yes, we are still limited to a single publish host, and only the "best" address from publish_host will be used, I do not change that, but its already the case today (even by default!: _local_), and its just an internal limitation we can later fix. Instead we just continue with the same logic of "magic selection of publish host", and users can always be explicit, and we are just clear to the user about what is happening.

I did it this way, because network stuff is already overwhelmed, and i mean really overwhelmed with settings. We need to make this easy on the user to do the right thing and not make that worse.

Examples:

bin/elasticsearch # defaults

[elasticsearch] [2015-10-06 01:15:28,671][WARN ][common.network           ] [Todd Arliss] publish host: [_local_] resolves to multiple addresses, auto-selecting {127.0.0.1} as single publish address
[elasticsearch] [2015-10-06 01:15:28,672][INFO ][transport                ] [Todd Arliss] publish_address {127.0.0.1:9300}, bound_addresses {[fe80::1]:9300}, {[::1]:9300}, {127.0.0.1:9300}

bin/elasticsearch -Des.network.host=_lo0_,_en0_ # multiple interfaces

[2015-10-06 01:17:08,970][WARN ][common.network           ] [Torso] publish host: [_lo0_, _en0_] resolves to multiple addresses, auto-selecting {192.168.0.19} as single publish address
[2015-10-06 01:17:08,972][INFO ][transport                ] [Torso] publish_address {192.168.0.19:9300}, bound_addresses {[fe80::1]:9300}, {[::1]:9300}, {127.0.0.1:9300}, {[fe80::3e15:c2ff:fee5:d26c]:9300}, {192.168.0.19:9300}

bin/elasticsearch -Des.network.host=192.168.0.19,_local_ -Des.network.publish_host=192.168.0.19 # being explicit

[2015-10-06 01:19:28,603][INFO ][transport                ] [Thunderbird] publish_address {192.168.0.19:9300}, bound_addresses {[fe80::1]:9300}, {[::1]:9300}, {127.0.0.1:9300}, {192.168.0.19:9300}

Closes #13592

For consistency and simplicity this means that es.network.host/bind_host/publish_host can all take arrays. Yes, we are still limited to a single publish host, and only the "best" address from publish_host will be used, I do not change that, but its alread the case today (even by default: _local_ !), and its just an internal limitation we can later fix. Instead we just continue with the same logic of "magic selection of publish host", and users can always be explicit, and weare just clear to the user about what is happening. I did it this way, because network stuff is already overwhelmed, and i mean really overwhelmed with settings. We need to make this easy on the user to do the right thing and not make that worse. Examples: bin/elasticsearch # defaults ``` [elasticsearch] [2015-10-06 01:15:28,671][WARN ][common.network ] [Todd Arliss] publish host: [_local_] resolves to multiple addresses, auto-selecting {127.0.0.1} as single publish address [elasticsearch] [2015-10-06 01:15:28,672][INFO ][transport ] [Todd Arliss] publish_address {127.0.0.1:9300}, bound_addresses {[fe80::1]:9300}, {[::1]:9300}, {127.0.0.1:9300} ``` bin/elasticsearch -Des.network.host=_lo0_,_en0_ # multiple interfaces ``` [2015-10-06 01:17:08,970][WARN ][common.network ] [Torso] publish host: [_lo0_, _en0_] resolves to multiple addresses, auto-selecting {192.168.0.19} as single publish address [2015-10-06 01:17:08,972][INFO ][transport ] [Torso] publish_address {192.168.0.19:9300}, bound_addresses {[fe80::1]:9300}, {[::1]:9300}, {127.0.0.1:9300}, {[fe80::3e15:c2ff:fee5:d26c]:9300}, {192.168.0.19:9300} ``` bin/elasticsearch -Des.network.host=192.168.0.19,_local_ -Des.network.publish_host=192.168.0.19 # being explicit ``` [2015-10-06 01:19:28,603][INFO ][transport ] [Thunderbird] publish_address {192.168.0.19:9300}, bound_addresses {[fe80::1]:9300}, {[::1]:9300}, {127.0.0.1:9300}, {192.168.0.19:9300} ``` Closes elastic#13592

* Deprecate _non_loopback_. This is far too arbitrary * Fix _local_ to mean loopback addresses, not addresses on loopback interfaces. This removes the confusion of e.g. binding to link-local addresses on the mac for example. * Remove internal use of _non_loopback_, instead just "expand wildcard addresses" * Add _site_ and _global_ scopes as counterparts to _local_. This means users can configure networking by address(es), interface(es), or scope (local, private, public), or any combination thereof.

rmuir · 2015-10-06T18:34:40Z

I pushed another commit that fixes the _local_ to behave more sanely, instead of "all the addresses of loopback interfaces" it means "all the loopback addresses". This is an important difference, e.g. it means we no longer confusingly bind to link-local addresses like fe80::1%lo0 on the mac.

I added _site_ and _global_ to match _local_. This means users can configure network binding by reachability scope(s), interface(s), address(es), or any combination of those.

e.g. stuff like -Des.network.host=_local_,_site_ will bind to 127.0.0.1, ::1, and 192.168.1.1, but not public addresses like 92.1.2.3

I am hoping this is enough to prevent confusing options in issues such as #13612 and #13972

If we need to fix this for 2.0 in order to fix those issues, then fine, lets do things right. But our network configuration needs to be easy and make logical sense :)

nik9000 · 2015-10-06T18:47:18Z

[2015-10-06 01:17:08,972][INFO ][transport                ] [Torso] publish_address {192.168.0.19:9300}, bound_addresses {[fe80::1]:9300}, {[::1]:9300}, {127.0.0.1:9300}, {[fe80::3e15:c2ff:fee5:d26c]:9300}, {192.168.0.19:9300}

Nice!

If we need to fix this for 2.0 in order to fix those issues, then fine, lets do things right. But our network configuration needs to be easy and make logical sense :)

I'm +1 on getting this back to 2.1. I'd love to get it into 2.0.1 when that comes around too.

nik9000 · 2015-10-06T18:49:41Z

core/src/main/java/org/elasticsearch/common/network/NetworkService.java

-        if (bindHost == null) {
-            bindHost = DEFAULT_NETWORK_HOST;
+        if (bindHosts == null) {
+            bindHosts = new String[] { DEFAULT_NETWORK_HOST };


Should it become DEFAULT_NETWORK_HOSTS?

our default is a single host specification: _local_. One point of this change is that you can use multiple: e.g. _local_,12.1.4.2,foo.bar.com

Yeah - I suppose that is fine reasoning.

rmuir · 2015-10-06T21:30:53Z

@nik9000 and for the record i don't really want to rush this stuff in. I just mention that in response to things like #13972 which are set for 2.0

Maybe it is those that need to be reconsidered instead as far as versioning? I am heavily concerned about being able to fix this stuff, I don't want to hear whimpering and whining about how fixing it in 2.2 is "breaking bwc", and i also don't want 2.0 to go out with massive security problems: I am doing everything I can to prevent that.

dadoonet · 2015-10-06T21:36:23Z

@rmuir There is IMO absolutely no rush to fix #13969 #13970 and #13972 although I marked them initially for 2.0.0. Just because people can use _local_ or _ec2_ for now so they have a workaround.

So if there is any security concern, let's move those issues to a later version. It's only a nice to have I think.

rmuir · 2015-10-06T21:39:14Z

OK I just feel like i missed something bigtime: some discussion that we are reverting the "bind-to-localhost" default in terms of ease of use.

This should really be discussed in more detail and planned more thoroughly. I saw a bunch of 2.0 issues come up suddenly and just got super worried about it.

On the other hand binding to localhost only as a default always, its very safe and easy to understand.

nik9000 · 2015-10-06T21:46:31Z

Maybe it is those that need to be reconsidered instead as far as versioning? I am heavily concerned about being able to fix this stuff, I don't want to hear whimpering and whining about how fixing it in 2.2 is "breaking bwc", and i also don't want 2.0 to go out with massive security problems: I am doing everything I can to prevent that.

If we're concerned about breaking backwards compatibility we can make those network addresses either strings or arrays. That seems simple enough and might be worth doing anyway.

On the other hand binding to localhost only as a default always, its very safe and easy to understand.

Yeah. I think it'd be nice to have some "this is how you make a real cluster" docs somewhere for users who want a helping hand going from playing around on one box to multiple boxes.

nik9000 · 2015-10-06T21:46:51Z

Yeah. I think it'd be nice to have some "this is how you make a real cluster" docs somewhere for users who want a helping hand going from playing around on one box to multiple boxes.

But not as part of this PR. That'd be silly.

rmuir · 2015-10-06T21:54:25Z

I'm removing 2.2 and will just remove the garbage like _non_loopback_ in our network configuration completely here in additional commits. It is far more important to clean up master. Otherwise things like deprecation and leniency hang around for too long.

Conflicts: core/src/main/java/org/elasticsearch/common/network/NetworkService.java

…d warnings

rmuir · 2015-10-15T22:45:14Z

I pushed additional commits with the cleanups I wanted to do. I think this is good for master. if we want to backport it (e.g. to 2.2) then we should deprecate+warn about the heuristicy _non_loopback_ that will be removed.

rmuir · 2015-10-23T12:27:09Z

I'm not going to maintain this branch, its too much work

s1monw · 2015-10-23T12:37:23Z

I looked through it and it LGTM I am sorry I missed the last pings 8 days ago, can you merge it when it's up-to-date?

rmuir · 2015-10-23T13:28:49Z

i resynced this to master.

jaymode · 2015-10-23T13:40:59Z

LGTM too

s1monw · 2015-10-23T19:39:29Z

LGTM thanks rob

* Allow for multiple host specifications (e.g. _en0_,192.168.1.2,_site_). * Add _site_ and _global_ scopes as counterparts to _local_. * Warn on heuristic selection of publish address. * Remove the arbitrary _non_loopback_ setting. Closes #13954 Conflicts: docs/reference/migration/migrate_3_0.asciidoc plugins/cloud-gce/src/test/java/org/elasticsearch/discovery/gce/GceNetworkTests.java

rmuir added v5.0.0-alpha1 v2.2.0 labels Oct 6, 2015

clintongormley added >enhancement :Distributed Coordination/Network Http and internode communication implementations review >feature and removed >enhancement labels Oct 6, 2015

nik9000 reviewed Oct 6, 2015
View reviewed changes

dadoonet mentioned this pull request Oct 6, 2015

Add _gce_ network host setting #13612

Merged

rmuir removed the v2.2.0 label Oct 6, 2015

rmuir added 3 commits October 15, 2015 18:19

Merge branch 'master' into multiple_addresses

af8e711

Conflicts: core/src/main/java/org/elasticsearch/common/network/NetworkService.java

include link-local addresses from loopback interfaces in _local_

11b1fa2

Remove the crazy non_loopback (can be deprecated) and add examples an…

b9cbd7f

…d warnings

Fix new unit tests from master merge

d7babe4

rmuir closed this Oct 23, 2015

Merge branch 'master' into multiple_addresses

5c9a4de

rmuir reopened this Oct 23, 2015

rmuir added the v2.2.0 label Oct 23, 2015

rmuir closed this in 6c8e290 Oct 24, 2015

rmuir mentioned this pull request Nov 13, 2015

Document wildcard for network interfaces in Network Settings #14607

Closed

rmuir mentioned this pull request Dec 9, 2015

network.bind_host does not support arrays #15340

Closed

dadoonet mentioned this pull request Dec 15, 2015

Elasticsearch 2.1.0 does not bind to multiple interfaces #15435

Closed

karmi mentioned this pull request Jan 8, 2016

Config options given as array sous-chefs/elasticsearch#419

Closed

martinb3 mentioned this pull request Jan 20, 2016

How to define discovery.zen.ping.unicast.hosts sous-chefs/elasticsearch#426

Closed

clever-trevor mentioned this pull request Feb 10, 2016

Document network changes in 2.2.0 #16406

Closed

dadoonet mentioned this pull request Mar 19, 2016

network.host _[networkInterface]_ not working in Centos 6.5 #17196

Closed

jpcarey mentioned this pull request Apr 11, 2016

Default host to localhost instead of empty string? elastic/support-diagnostics#100

Closed

astralblue mentioned this pull request Sep 30, 2016

Binding to the wildcard of one address family should not prevent binding to addresses in another family #20703

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow binding to multiple addresses. #13954

Allow binding to multiple addresses. #13954

rmuir commented Oct 6, 2015

rmuir commented Oct 6, 2015

nik9000 commented Oct 6, 2015

nik9000 Oct 6, 2015

rmuir Oct 6, 2015

nik9000 Oct 6, 2015

rmuir commented Oct 6, 2015

dadoonet commented Oct 6, 2015

rmuir commented Oct 6, 2015

nik9000 commented Oct 6, 2015

nik9000 commented Oct 6, 2015

rmuir commented Oct 6, 2015

rmuir commented Oct 15, 2015

rmuir commented Oct 23, 2015

s1monw commented Oct 23, 2015

rmuir commented Oct 23, 2015

jaymode commented Oct 23, 2015

s1monw commented Oct 23, 2015

Allow binding to multiple addresses. #13954

Allow binding to multiple addresses. #13954

Conversation

rmuir commented Oct 6, 2015

rmuir commented Oct 6, 2015

nik9000 commented Oct 6, 2015

nik9000 Oct 6, 2015

Choose a reason for hiding this comment

rmuir Oct 6, 2015

Choose a reason for hiding this comment

nik9000 Oct 6, 2015

Choose a reason for hiding this comment

rmuir commented Oct 6, 2015

dadoonet commented Oct 6, 2015

rmuir commented Oct 6, 2015

nik9000 commented Oct 6, 2015

nik9000 commented Oct 6, 2015

rmuir commented Oct 6, 2015

rmuir commented Oct 15, 2015

rmuir commented Oct 23, 2015

s1monw commented Oct 23, 2015

rmuir commented Oct 23, 2015

jaymode commented Oct 23, 2015

s1monw commented Oct 23, 2015