Core: Default node.name to the hostname#33677
Conversation
Changes the default of the `node.name` setting to the hostname of the machine on which Elasticsearch is running. Previously it was the first 8 characters of the node id. This had the advantage of producing a unique name even when the node name isn't configured but the disadvantage of being unrecognizable and not being available until fairly late in the startup process. Of particular interest is that it isn't available until after logging is configured. This forces us to use a volatile read whenever we add the node name to the log. Using the hostname is available immediately on startup and is generally recognizable but has the disadvantage of not being unique when run on machines that don't set their hostname or when multiple elasticsearch processes are run on the same host. I believe that, taken together, it is better to default to the hostname. 1. Running multiple copies of Elasticsearch on the same node is a fairly advanced feature. We do it all the as part of the elasticsearch build for testing but we make sure to set the node name then. 2. That the node.name defaults to some flavor of "localhost" on an unconfigured box feels like it isn't going to come up too much in production. I expect most production deployments to at least set the hostname. As a bonus, production deployments need no longer set the node name in most cases. At least in my experience most folks set it to the hostname anyway.
|
Pinging @elastic/es-core-infra |
|
I've marked this as discuss because I bunch of us talked about this and thought it was a good idea but we are aware that other contributors have thought otherwise in the past and might still not like this idea. |
|
We discussed this during Fix-it-Thursday and have consensus to move ahead with this proposal. |
❤️ |
|
The test failure is mine. I'm looking into it. I still need to go through the docs some more. And write a breaking changes note for this. |
| Elasticsearch uses `node.name` as a human readable identifier for a | ||
| particular instance of Elasticsearch so it is included in the response | ||
| of many APIs. It defaults to the hostname that the machine has when | ||
| Elasticsearch starts. If you'd prefer a different identifier then you |
There was a problem hiding this comment.
I would word this a little less colloquially:
It defaults to the hostname of the machine when Elasticsearch starts, but can be configured explicitly in
elasticsearch.ymlas follows:
|
I think I need to do some testing work on this before it is ready. I'm seeing a few things I hadn't thought about. |
| final Settings settings = builder.build(); | ||
| final Settings settings = Settings.builder() | ||
| .put("cluster.name", randomAlphaOfLength(16)) | ||
| .put("node.name", randomAlphaOfLength(16)) |
There was a problem hiding this comment.
node.name is always available at this point in the course of normal operation.
|
|
||
| public void testNoNodeNameInPatternWarning() throws IOException, UserException { | ||
| String nodeName = randomAlphaOfLength(16); | ||
| LogConfigurator.setNodeName(nodeName); |
There was a problem hiding this comment.
Since we automatically add a node name to the pattern we need to configure one or else the NodeNamePatternConverter will refuse to be built.
| }); | ||
| } | ||
|
|
||
| public void testDummy() { |
There was a problem hiding this comment.
I'm glad to remove this!
| ==== The default for `node.name` is now the hostname | ||
|
|
||
| `node.name` now defaults to the hostname at the time when Elasticsearch | ||
| is started. We hope that this is a more generally useful default than |
There was a problem hiding this comment.
I would replace the second sentence with:
Previously the default node name was the first eight characters of the node id. It can still be configured explicitly in
elasticsearch.yml.
|
@nik9000 was it discussed whether we should prevent joins of nodes with a name that clashes with an existing node in the cluster? |
I wasn't around for the discussion. I'm not sure where I come down on the issue. It does feel like a sign of a configuration problem though so I think it'd be fair to prevent such joins. |
I suppose what I mean is that I think it'd be a good check to do and the argument to prevent joins where the node names match is pretty good. I'm not 100% sure it is worth implementing it but I feel like I could be convinced. |
Changes the default of the
node.namesetting to the hostname of themachine on which Elasticsearch is running. Previously it was the first 8
characters of the node id. This had the advantage of producing a unique
name even when the node name isn't configured but the disadvantage of
being unrecognizable and not being available until fairly late in the
startup process. Of particular interest is that it isn't available until
after logging is configured. This forces us to use a volatile read
whenever we add the node name to the log.
Using the hostname is available immediately on startup and is generally
recognizable but has the disadvantage of not being unique when run on
machines that don't set their hostname or when multiple elasticsearch
processes are run on the same host. I believe that, taken together, it
is better to default to the hostname.
advanced feature. We do it all the as part of the elasticsearch build
for testing but we make sure to set the node name then.
unconfigured box feels like it isn't going to come up too much in
production. I expect most production deployments to at least set the
hostname.
As a bonus, production deployments need no longer set the node name in
most cases. At least in my experience most folks set it to the hostname
anyway.