2022-02-02 00:54:57 +08:00
|
|
|
[[update-desired-nodes]]
|
|
|
|
=== Create or update desired nodes API
|
|
|
|
++++
|
|
|
|
<titleabbrev>Create or update desired nodes</titleabbrev>
|
|
|
|
++++
|
|
|
|
|
|
|
|
NOTE: {cloud-only}
|
|
|
|
|
|
|
|
Creates or updates the desired nodes.
|
|
|
|
|
|
|
|
[[update-desired-nodes-request]]
|
|
|
|
==== {api-request-title}
|
|
|
|
|
|
|
|
[source,console]
|
|
|
|
--------------------------------------------------
|
|
|
|
PUT /_internal/desired_nodes/<history_id>/<version>
|
|
|
|
{
|
|
|
|
"nodes" : [
|
|
|
|
{
|
|
|
|
"settings" : {
|
|
|
|
"node.name" : "instance-000187",
|
|
|
|
"node.external_id": "instance-000187",
|
|
|
|
"node.roles" : ["data_hot", "master"],
|
|
|
|
"node.attr.data" : "hot",
|
|
|
|
"node.attr.logical_availability_zone" : "zone-0"
|
|
|
|
},
|
Add support for CPU ranges in desired nodes (#86434)
This commit adds support for CPU ranges in the desired nodes API.
This aligns better with environments where administrators/orchestrators
can define lower and upper bounds for the amount of CPUs that the
desired node would get once deployed.
This allows to provide information about the expected CPU and possible
allowed overcommit that the desired node will run on.
This was the previous expected body for the desired nodes API (we still support it):
```
PUT /_internal/desired_nodes/history/1
{
"nodes" : [
{
"settings" : {
"node.name" : "instance-000187",
"node.external_id": "instance-000187",
"node.roles" : ["data_hot", "master"],
"node.attr.data" : "hot",
"node.attr.logical_availability_zone" : "zone-0"
},
"processors" : 8,
"memory" : "58gb",
"storage" : "1700gb",
"node_version" : "8.3.0"
}
]
}
```
Now it's possible to define `processors` or `processors_range` as in:
```
PUT /_internal/desired_nodes/history/1
{
"nodes" : [
{
"settings" : {
"node.name" : "instance-000187",
"node.external_id": "instance-000187",
"node.roles" : ["data_hot", "master"],
"node.attr.data" : "hot",
"node.attr.logical_availability_zone" : "zone-0"
},
"processors_range" : {"min": 8.0, "max": 16.0},
"memory" : "58gb",
"storage" : "1700gb",
"node_version" : "8.3.0"
}
]
}
```
Note that `max` in `processors_range` is optional.
This commit also moves from representing CPUs as integers to
accept floating point numbers.
Note: I disabled the bwc yamlRestTests for versions < 8.3 since we introduced
a few "breaking changes" but since this is an internal API it should be fine.
2022-05-20 17:47:32 +08:00
|
|
|
"processors" : 8.0,
|
2022-02-02 00:54:57 +08:00
|
|
|
"memory" : "58gb",
|
Add support for CPU ranges in desired nodes (#86434)
This commit adds support for CPU ranges in the desired nodes API.
This aligns better with environments where administrators/orchestrators
can define lower and upper bounds for the amount of CPUs that the
desired node would get once deployed.
This allows to provide information about the expected CPU and possible
allowed overcommit that the desired node will run on.
This was the previous expected body for the desired nodes API (we still support it):
```
PUT /_internal/desired_nodes/history/1
{
"nodes" : [
{
"settings" : {
"node.name" : "instance-000187",
"node.external_id": "instance-000187",
"node.roles" : ["data_hot", "master"],
"node.attr.data" : "hot",
"node.attr.logical_availability_zone" : "zone-0"
},
"processors" : 8,
"memory" : "58gb",
"storage" : "1700gb",
"node_version" : "8.3.0"
}
]
}
```
Now it's possible to define `processors` or `processors_range` as in:
```
PUT /_internal/desired_nodes/history/1
{
"nodes" : [
{
"settings" : {
"node.name" : "instance-000187",
"node.external_id": "instance-000187",
"node.roles" : ["data_hot", "master"],
"node.attr.data" : "hot",
"node.attr.logical_availability_zone" : "zone-0"
},
"processors_range" : {"min": 8.0, "max": 16.0},
"memory" : "58gb",
"storage" : "1700gb",
"node_version" : "8.3.0"
}
]
}
```
Note that `max` in `processors_range` is optional.
This commit also moves from representing CPUs as integers to
accept floating point numbers.
Note: I disabled the bwc yamlRestTests for versions < 8.3 since we introduced
a few "breaking changes" but since this is an internal API it should be fine.
2022-05-20 17:47:32 +08:00
|
|
|
"storage" : "2tb",
|
2022-02-03 05:29:02 +08:00
|
|
|
"node_version" : "{version}"
|
2022-02-02 00:54:57 +08:00
|
|
|
}
|
|
|
|
]
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
|
|
|
// TEST[s/<history_id>/test/]
|
|
|
|
// TEST[s/<version>/1/]
|
|
|
|
|
|
|
|
//////////////////////////
|
|
|
|
|
|
|
|
[source,console]
|
|
|
|
--------------------------------------------------
|
|
|
|
DELETE /_internal/desired_nodes
|
|
|
|
--------------------------------------------------
|
|
|
|
// TEST[continued]
|
|
|
|
|
|
|
|
//////////////////////////
|
|
|
|
|
|
|
|
[[update-desired-nodes-query-params]]
|
|
|
|
==== {api-query-parms-title}
|
|
|
|
|
|
|
|
include::{es-repo-dir}/rest-api/common-parms.asciidoc[tag=master-timeout]
|
|
|
|
|
2022-07-26 15:03:12 +08:00
|
|
|
`dry_run`::
|
|
|
|
(Optional, Boolean) If `true`, then the request simulates the update and
|
|
|
|
returns a response with `dry_run` field set to `true`.
|
|
|
|
|
2022-02-02 00:54:57 +08:00
|
|
|
[[update-desired-nodes-desc]]
|
|
|
|
==== {api-description-title}
|
|
|
|
|
|
|
|
This API creates or update the desired nodes. External orchestrators can use
|
|
|
|
this API to let Elasticsearch know about the cluster topology, including future
|
|
|
|
changes such as adding or removing nodes. Using this information, the system is
|
|
|
|
able to take better decisions.
|
|
|
|
|
2022-07-26 15:03:12 +08:00
|
|
|
It's possible to run the update in "dry run" mode by adding the
|
|
|
|
`?dry_run` query parameter. This will validate the request result, but will not actually perform the update.
|
|
|
|
|
2022-02-02 00:54:57 +08:00
|
|
|
[[update-desired-nodes-examples]]
|
|
|
|
==== {api-examples-title}
|
|
|
|
|
|
|
|
In this example, a new version for the desired nodes with history `Ywkh3INLQcuPT49f6kcppA` is created.
|
|
|
|
This API only accepts monotonically increasing versions.
|
|
|
|
|
|
|
|
[source,console]
|
|
|
|
--------------------------------------------------
|
|
|
|
PUT /_internal/desired_nodes/Ywkh3INLQcuPT49f6kcppA/100
|
|
|
|
{
|
|
|
|
"nodes" : [
|
|
|
|
{
|
|
|
|
"settings" : {
|
|
|
|
"node.name" : "instance-000187",
|
|
|
|
"node.external_id": "instance-000187",
|
|
|
|
"node.roles" : ["data_hot", "master"],
|
|
|
|
"node.attr.data" : "hot",
|
|
|
|
"node.attr.logical_availability_zone" : "zone-0"
|
|
|
|
},
|
Add support for CPU ranges in desired nodes (#86434)
This commit adds support for CPU ranges in the desired nodes API.
This aligns better with environments where administrators/orchestrators
can define lower and upper bounds for the amount of CPUs that the
desired node would get once deployed.
This allows to provide information about the expected CPU and possible
allowed overcommit that the desired node will run on.
This was the previous expected body for the desired nodes API (we still support it):
```
PUT /_internal/desired_nodes/history/1
{
"nodes" : [
{
"settings" : {
"node.name" : "instance-000187",
"node.external_id": "instance-000187",
"node.roles" : ["data_hot", "master"],
"node.attr.data" : "hot",
"node.attr.logical_availability_zone" : "zone-0"
},
"processors" : 8,
"memory" : "58gb",
"storage" : "1700gb",
"node_version" : "8.3.0"
}
]
}
```
Now it's possible to define `processors` or `processors_range` as in:
```
PUT /_internal/desired_nodes/history/1
{
"nodes" : [
{
"settings" : {
"node.name" : "instance-000187",
"node.external_id": "instance-000187",
"node.roles" : ["data_hot", "master"],
"node.attr.data" : "hot",
"node.attr.logical_availability_zone" : "zone-0"
},
"processors_range" : {"min": 8.0, "max": 16.0},
"memory" : "58gb",
"storage" : "1700gb",
"node_version" : "8.3.0"
}
]
}
```
Note that `max` in `processors_range` is optional.
This commit also moves from representing CPUs as integers to
accept floating point numbers.
Note: I disabled the bwc yamlRestTests for versions < 8.3 since we introduced
a few "breaking changes" but since this is an internal API it should be fine.
2022-05-20 17:47:32 +08:00
|
|
|
"processors" : 8.0,
|
2022-02-02 00:54:57 +08:00
|
|
|
"memory" : "58gb",
|
Add support for CPU ranges in desired nodes (#86434)
This commit adds support for CPU ranges in the desired nodes API.
This aligns better with environments where administrators/orchestrators
can define lower and upper bounds for the amount of CPUs that the
desired node would get once deployed.
This allows to provide information about the expected CPU and possible
allowed overcommit that the desired node will run on.
This was the previous expected body for the desired nodes API (we still support it):
```
PUT /_internal/desired_nodes/history/1
{
"nodes" : [
{
"settings" : {
"node.name" : "instance-000187",
"node.external_id": "instance-000187",
"node.roles" : ["data_hot", "master"],
"node.attr.data" : "hot",
"node.attr.logical_availability_zone" : "zone-0"
},
"processors" : 8,
"memory" : "58gb",
"storage" : "1700gb",
"node_version" : "8.3.0"
}
]
}
```
Now it's possible to define `processors` or `processors_range` as in:
```
PUT /_internal/desired_nodes/history/1
{
"nodes" : [
{
"settings" : {
"node.name" : "instance-000187",
"node.external_id": "instance-000187",
"node.roles" : ["data_hot", "master"],
"node.attr.data" : "hot",
"node.attr.logical_availability_zone" : "zone-0"
},
"processors_range" : {"min": 8.0, "max": 16.0},
"memory" : "58gb",
"storage" : "1700gb",
"node_version" : "8.3.0"
}
]
}
```
Note that `max` in `processors_range` is optional.
This commit also moves from representing CPUs as integers to
accept floating point numbers.
Note: I disabled the bwc yamlRestTests for versions < 8.3 since we introduced
a few "breaking changes" but since this is an internal API it should be fine.
2022-05-20 17:47:32 +08:00
|
|
|
"storage" : "2tb",
|
2022-02-03 05:29:02 +08:00
|
|
|
"node_version" : "{version}"
|
2022-02-02 00:54:57 +08:00
|
|
|
}
|
|
|
|
]
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
|
|
|
// TEST
|
|
|
|
|
|
|
|
The API returns the following result:
|
|
|
|
|
|
|
|
[source,console-result]
|
|
|
|
--------------------------------------------------
|
|
|
|
{
|
2022-07-26 15:03:12 +08:00
|
|
|
"replaced_existing_history_id": false,
|
|
|
|
"dry_run": false
|
2022-02-02 00:54:57 +08:00
|
|
|
}
|
|
|
|
--------------------------------------------------
|
|
|
|
|
Add support for CPU ranges in desired nodes (#86434)
This commit adds support for CPU ranges in the desired nodes API.
This aligns better with environments where administrators/orchestrators
can define lower and upper bounds for the amount of CPUs that the
desired node would get once deployed.
This allows to provide information about the expected CPU and possible
allowed overcommit that the desired node will run on.
This was the previous expected body for the desired nodes API (we still support it):
```
PUT /_internal/desired_nodes/history/1
{
"nodes" : [
{
"settings" : {
"node.name" : "instance-000187",
"node.external_id": "instance-000187",
"node.roles" : ["data_hot", "master"],
"node.attr.data" : "hot",
"node.attr.logical_availability_zone" : "zone-0"
},
"processors" : 8,
"memory" : "58gb",
"storage" : "1700gb",
"node_version" : "8.3.0"
}
]
}
```
Now it's possible to define `processors` or `processors_range` as in:
```
PUT /_internal/desired_nodes/history/1
{
"nodes" : [
{
"settings" : {
"node.name" : "instance-000187",
"node.external_id": "instance-000187",
"node.roles" : ["data_hot", "master"],
"node.attr.data" : "hot",
"node.attr.logical_availability_zone" : "zone-0"
},
"processors_range" : {"min": 8.0, "max": 16.0},
"memory" : "58gb",
"storage" : "1700gb",
"node_version" : "8.3.0"
}
]
}
```
Note that `max` in `processors_range` is optional.
This commit also moves from representing CPUs as integers to
accept floating point numbers.
Note: I disabled the bwc yamlRestTests for versions < 8.3 since we introduced
a few "breaking changes" but since this is an internal API it should be fine.
2022-05-20 17:47:32 +08:00
|
|
|
Additionally, it is possible to specify a processors range.
|
|
|
|
This is helpful in environments where Elasticsearch nodes can
|
|
|
|
be deployed in hosts where the number of processors that the
|
|
|
|
Elasticsearch process can use is guaranteed to be at least the
|
|
|
|
lower range and up to the upper range. This is a common scenario
|
|
|
|
in Linux deployments where cgroups is used.
|
|
|
|
[source,console]
|
|
|
|
--------------------------------------------------
|
|
|
|
PUT /_internal/desired_nodes/Ywkh3INLQcuPT49f6kcppA/101
|
|
|
|
{
|
|
|
|
"nodes" : [
|
|
|
|
{
|
|
|
|
"settings" : {
|
|
|
|
"node.name" : "instance-000187",
|
|
|
|
"node.external_id": "instance-000187",
|
|
|
|
"node.roles" : ["data_hot", "master"],
|
|
|
|
"node.attr.data" : "hot",
|
|
|
|
"node.attr.logical_availability_zone" : "zone-0"
|
|
|
|
},
|
|
|
|
"processors_range" : {"min": 8.0, "max": 10.0},
|
|
|
|
"memory" : "58gb",
|
|
|
|
"storage" : "2tb",
|
|
|
|
"node_version" : "{version}"
|
|
|
|
}
|
|
|
|
]
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
|
|
|
|
2022-02-02 00:54:57 +08:00
|
|
|
//////////////////////////
|
|
|
|
|
|
|
|
[source,console]
|
|
|
|
--------------------------------------------------
|
|
|
|
DELETE /_internal/desired_nodes
|
|
|
|
--------------------------------------------------
|
|
|
|
// TEST[continued]
|
|
|
|
|
|
|
|
//////////////////////////
|