String settings leniently accept lists

[DaveCTurner]

If you got here from the good first issue label, see this comment.

For example, the following elasticsearch.yml ...

node.name:
- node-a
- node-b

... starts up a node called [node-a, node-b]:

[2018-08-24T17:08:43,807][INFO ][o.e.n.Node               ] [[node-a, node-b]] initializing ...

In fact this is what's happening in #30946. The following API call...

PUT _cluster/settings
{
  "transient" : {
    "cluster.routing.allocation.exclude._name" : [ "elasticsearch-data-0" ]
  }
}

... sets cluster.routing.allocation.exclude._name to the string [elasticsearch-data-0], which then does not match the node called elasticsearch-data-0 so the allocation is not filtered as expected.

[elasticmachine]

Pinging @elastic/es-core-infra

[original-brownbear]

The fix broke 6.x Tribe tests, reopening ...
see #33660

[original-brownbear]

@s1monw @jasontedor question here:

Is it true that the only reason we can't do 6075e15 is because they break the "dummy settings" used by Tribe here: https://github.com/elastic/elasticsearch/blob/6.x/modules/tribe/src/main/java/org/elasticsearch/tribe/TribePlugin.java#L177
... because those always assume String / scalar type for the dummies even if the key would in fact contain a list?

Or is this kind of hard validation a problem beyond just Tribe and we want to allow this kind of "validation" or mixed list and scalar settings in general?

[bczifra]

A use can specify node.attr.foo : [ "bar", "baz" ] in elasticsearch.yml, and Elasticsearch starts up without logging anything at all indicating that this is not supported behavior, so setting "index.routing.allocation.require.foo": "bar" won't match "[bar, baz]" and the index shards won't be allocated. This can be particularly confusing because allocation awareness attributes do support multiple values.

[gwbrown]

@original-brownbear Did you ever get an answer to your question? Can we reintroduce the fix now that Tribe has been removed?