Config options given as array

[lmickh]

Trying to configure the ES v2 yml file like so:

network.host:
 - _local_
 - _non_loopback_

Would be nice to be able to give the config options in an array that is converted to yml (a la to_yaml).

['elasticsearch']['config']['network.host'] = ['_local_', '_non_loopback_']

Instead it concats the array and generates this which is invalid:

network.host: _local_,_non_loopback_

If this behavior isn't desired, might consider having it error out instead.

[martinb3]

Hello! Indeed, we concatenate any arrays like you've discovered, mostly to support the various ES settings that take a list of values.

I don't see anything in the ES documentation that indicates that network.host can be used in the way your example does. Here's what I'm looking at for docs for v2.1: https://www.elastic.co/guide/en/elasticsearch/reference/2.1/modules-network.html

Can you point me to the documentation on what happens when you supply a YML list of values like you're trying to do?

[lmickh]

Unfortunately the documentation is not clear, but as of v2 the options must be given in a proper yaml format. Not as comma separated values like they were in previous versions.

https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-configuration.html#settings

When I try to start ES with the the config file as generated by the cookbook, it will fail to run because "local,non_loopback" is not a valid option.

[2016-01-06 16:08:33,804][ERROR][bootstrap                ] [host.example.com] Exception
java.lang.IllegalArgumentException: No interface named 'local_,_non_loopback' found, got [name:lo (lo), name:eth0 (eth0)]
        at org.elasticsearch.common.network.NetworkUtils.getAddressesForInterface(NetworkUtils.java:188)
....

When the values are separated in a proper yaml format, the configuration functions as expected.

[martinb3]

It sounds like we should definitely fix the YAML syntax, but -- what does it actually mean when you give a list of values to network.host?

the configuration functions as expected.

In other words, what does this do in a config file? What's "as expected"?

network.host:
 - _local_
 - _non_loopback_

I don't see any docs that say what should happen when that's a list of options.

[davidski]

Perhaps a simpler case where a YAML list comes into play is with the network.bind_host parameter, where a list can be provided to specify which interfaces Elasticsearch should be listening. A use case of providing multiple entries is to bind to a specific loopback and a primary public interface.

A S/O question talking about this is at http://stackoverflow.com/questions/29892934/elasticsearch-multiple-nic-bind-network-interfaces

[martinb3]

@davidski I appreciate those links, but I actually still can't find anywhere in the ES documentation that says we should be specifying things using a YAML list. I wonder if we need to go upstream and suggest they document that these configuration elements allow YAML lists? And document the behavior for many of the settings when YAML lists are supplied?

[karmi]

@martinb3 I'll ask the Elasticsearch developers how the correct syntax should look like. In case of a fix in Elasticsearch, it will be applicable only to new versions, though...

[karmi]

Upon consultation, this doesn't seem like a problem with the syntax itself, but with the ability to bind to multiple addresses, please see issues elastic/elasticsearch#13592 and elastic/elasticsearch#13954. @lmickh, can you try with ES 2.x or master and correct me if I'm wrong?

[martinb3]

Thank you for steering us to that issue @karmi! I had looked for existing issues but missed those. Maybe this is a good opportunity to add building from source to the cookbook, so we can test these things like this which could be fixed in master.

[karmi]

@martinb3 I had to consult with core developers to get that ticket :) And yes, it would be nice to add the source installation -- master currently switched to Gradle...

[lmickh]

Sorry for the delayed response.

@karmi Those issues are a problem. I may have jumped the gun a bit on this issue. Providing a yml list will create a config file with the proper syntax, but ES will silently ignore the extra network.host value per the issues linked above. I didn't read anything in the docs that indicated there could be only one value so I didn't think to validate the ES service was actually behaving that way at the time. Just looked to see that the config file was accepted.

[martinb3]

I'm going to close this, given that it was fixed upstream.