Disk watermark validation rejects apparently valid sequence of updates #28309
Description
$ elasticsearch-6.1.1/bin/elasticsearch --version
Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
Version: 6.1.1, Build: bd92e7f/2017-12-17T20:23:25.338Z, JVM: 9.0.1
$ java -version
java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)
$ uname -a
Darwin Davids-MacBook-Pro.local 17.3.0 Darwin Kernel Version 17.3.0: Thu Nov 9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64 x86_64
On a fresh one-node cluster, the first of these operations succeeds but the second fails:
PUT _cluster/settings
{"transient":{"cluster.routing.allocation.disk.watermark.flood_stage":"99%"}}
PUT _cluster/settings
{"transient":{"cluster.routing.allocation.disk.watermark.high":"97%"}}
The result is:
{
"error": {
"root_cause": [
{
"type": "illegal_argument_exception",
"reason": "high disk watermark [97%] more than flood stage disk watermark [95%]"
}
],
"type": "illegal_argument_exception",
"reason": "high disk watermark [97%] more than flood stage disk watermark [95%]"
},
"status": 400
}
This is surprising because the flood stage watermark was set to 99% but the error message claims it is still 95%. As expected, GET _cluster/settings yields:
{
"persistent": {},
"transient": {
"cluster": {
"routing": {
"allocation": {
"disk": {
"watermark": {
"flood_stage": "99%"
}
}
}
}
}
}
}
Setting both watermarks together succeeds:
PUT _cluster/settings
{
"transient": {
"cluster.routing.allocation.disk.watermark.flood_stage": "99%",
"cluster.routing.allocation.disk.watermark.high": "97%"
}
}
I see the same effect replacing transient with persistent throughout too.
Metadata
Metadata
Assignees
Type
Fields
Give feedbackNo fields configured for issues without a type.