Unify terminology for coordinating node (#12478)

* Unify terminology for coordinating node

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

* Add the word node to node definitions

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

---------

Signed-off-by: Fanit Kolchina <kolchfa@amazon.com>

Author: kolchfa-aws

_about/version-history.md

@@ -38,7 +38,7 @@ OpenSearch version | Release highlights | Release date
 [2.9.0](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.9.0.md) | Makes search pipelines and the Neural Search plugin generally available. Adds ML model access control and integration with external ML tools. Implements k-NN byte vectors and efficient filtering with the Faiss engine. Integrates alerting and anomaly detection with OpenSearch Dashboards and adds composite monitors. Adds two new index codec algorithm options. Includes a new ingestion schema for Security Analytics, geoshape aggregations, and extensions---a new mechanism for extending OpenSearch functionality. For a full list of release highlights, see the [Release Notes](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.9.0.md). | 24 July 2023
 [2.8.0](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.8.0.md) | Adds cross-cluster query with PPL, search pipelines, an option to turn on segment replication as the default replication type, improved searchable snapshot performance, and Amazon OpenSearch Serverless support with SigV4 authentication for multiple data sources. Includes the UI for the flush, refresh, and clear cache operations in OpenSearch Dashboards. For a full list of release highlights, see the [Release Notes](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.8.0.md). | 06 June 2023
 [2.7.0](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.7.0.md) | Includes searchable snapshots and segment replication, which are now generally available. Adds multiple data sources, observability features, dynamic tenant management, component templates, and shape-based map filters in OpenSearch Dashboards. Includes the flat object field type, hot shard identification, and a new automatic reloading mechanism for ML models. For a full list of release highlights, see the [Release Notes](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.7.0.md). | 02 May 2023
-[2.6.0](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.6.0.md) | Includes simple schema for observability, index management UI enhancements, Security Analytics enhancements, search backpressure at the coordinator node level, and the ability to add maps to dashboards. Experimental features include a new ML model health dashboard, new text embedding models in ML, and SigV4 authentication in Dashboards. For a full list of release highlights, see the [Release Notes](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.6.0.md). | 28 February 2023
+[2.6.0](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.6.0.md) | Includes simple schema for observability, index management UI enhancements, Security Analytics enhancements, search backpressure at the coordinating node level, and the ability to add maps to dashboards. Experimental features include a new ML model health dashboard, new text embedding models in ML, and SigV4 authentication in Dashboards. For a full list of release highlights, see the [Release Notes](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.6.0.md). | 28 February 2023
 [2.5.0](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.5.0.md) | Includes index management UI enhancements, multi-layer maps, Jaeger support for observability, Debian distributions, returning cluster health by awareness attribute, cluster manager task throttling, weighted zonal search request routing policy, and query string support in index rollups. Experimental features include request-level durability in remote-backed storage and GPU acceleration for ML nodes. For a full list of release highlights, see the [Release Notes](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.5.0.md). | 24 January 2023
 [2.4.1](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.4.1.md) | Includes maintenance changes and bug fixes for gradle check and indexing pressure tests. Adds support for skipping changelog. For a full list of release highlights, see the [Release Notes](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.4.1.md). | 13 December 2022
 [2.4.0](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.4.0.md) | Includes Windows support, Point-in-time search, custom k-NN filtering, xy_point and xy_shape field types for Cartesian coordinates, GeoHex grid aggregation, and resilience enhancements, including search backpressure. In OpenSearch Dashboards, this release adds snapshot restore functionality, multiple authentication, and aggregate view of saved objects. This release includes the following experimental features: searchable snapshots, Compare Search Results, multiple data sources in OpenSearch Dashboards, a new Model Serving Framework in ML Commons, a new Neural Search plugin that supports semantic search, and a new Security Analytics plugin to analyze security logs. For a full list of release highlights, see the [Release Notes](https://github.com/opensearch-project/opensearch-build/blob/main/release-notes/opensearch-release-notes-2.4.0.md). | 15 November 2022

_install-and-configure/configuring-opensearch/search-settings.md

@@ -37,7 +37,7 @@ OpenSearch supports the following search settings:
 
 - `search.max_open_scroll_context` (Dynamic, integer): A node-level setting that specifies the maximum number of open scroll contexts for the node. Default is `500`.
 
-- `search.request_stats_enabled` (Dynamic, Boolean): Turns on node-level collection of phase-timing statistics from the perspective of the coordinator node. The request-level statistics keep track of how long (in total) search requests spend in each of the different search phases. You can retrieve these counters using the [Nodes Stats API]({{site.url}}{{site.baseurl}}/api-reference/nodes-apis/nodes-stats/). Default is `false`.
+- `search.request_stats_enabled` (Dynamic, Boolean): Turns on node-level collection of phase-timing statistics from the perspective of the coordinating node. The request-level statistics keep track of how long (in total) search requests spend in each of the different search phases. You can retrieve these counters using the [Nodes Stats API]({{site.url}}{{site.baseurl}}/api-reference/nodes-apis/nodes-stats/). Default is `false`.
 
 - `search.highlight.term_vector_multi_value` (Static, Boolean): Specifies to highlight snippets across values of a multi-valued field. Default is `true`.
 

_observing-your-data/query-insights/live-queries.md

@@ -133,8 +133,8 @@ GET /_insights/live_queries?wlmGroupId=DEFAULT_WORKLOAD_GROUP
 The preceding response shows a single live query:
 
 - The top-level fields (`id`, `status`, `start_time`, `total_latency_millis`, `total_cpu_nanos`, `total_memory_bytes`) provide a summary of the entire search request. The `total_*` metrics are aggregated across the coordinator task and all shard tasks, giving you a single view of the query's overall resource consumption.
-- The `coordinator_task` object describes the task on the coordinator node that received the search request and is orchestrating the query across shards. In this example, the coordinator node (`troGHNGUShqDj3wK_K5ZIw`) has been running for approximately 13.9 seconds and has consumed 305,000 nanoseconds of CPU time and 2,048 bytes of memory. The `description` field includes the target indexes, search type, and the full query source.
-- The `shard_tasks` array lists the individual shard-level tasks spawned by the coordinator node. Each shard task runs on a specific data node and executes a phase of the search (for example, `search[phase/query]`). In this example, one shard task is running on node `Y6eBnbdISPO6XaVfxCBRgg`, consuming 100,000 nanoseconds of CPU and 1,056 bytes of memory. A query that spans multiple shards or data nodes will have multiple entries in this array.
+- The `coordinator_task` object describes the task on the coordinating node that received the search request and is orchestrating the query across shards. In this example, the coordinating node (`troGHNGUShqDj3wK_K5ZIw`) has been running for approximately 13.9 seconds and has consumed 305,000 nanoseconds of CPU time and 2,048 bytes of memory. The `description` field includes the target indexes, search type, and the full query source.
+- The `shard_tasks` array lists the individual shard-level tasks spawned by the coordinating node. Each shard task runs on a specific data node and executes a phase of the search (for example, `search[phase/query]`). In this example, one shard task is running on node `Y6eBnbdISPO6XaVfxCBRgg`, consuming 100,000 nanoseconds of CPU and 1,056 bytes of memory. A query that spans multiple shards or data nodes will have multiple entries in this array.
 
 When `use_finished_cache=true` is specified, the response also includes a `finished_queries` array:
 
@@ -191,7 +191,7 @@ The following table lists the fields in each object in the `live_queries` array.
 
 | Field | Data type | Description |
 | :--- | :--- | :--- |
-| `id` | String | The unique identifier of the search request (the coordinator node task ID in `nodeId:taskId` format). |
+| `id` | String | The unique identifier of the search request (the coordinating node task ID in `nodeId:taskId` format). |
 | `status` | String | The current status of the query. Valid values are `running` or `cancelled`. |
 | `start_time` | Long | The time at which the query started, in milliseconds since the epoch. |
 | `wlm_group_id` | String | The workload management group ID associated with the query. Only present if the query belongs to a workload group. |
@@ -227,7 +227,7 @@ When `use_finished_cache=true` is specified, the `finished_queries` array contai
 | `id` | String | The live query identifier (in `nodeId:taskId` format) for correlation with live queries. |
 | `top_n_id` | String | The UUID linking this record to the corresponding top N query record. May be `null` if the query did not qualify as a top N query. |
 | `status` | String | The completion status of the query (for example, `completed`). |
-| `node_id` | String | The coordinator node ID. |
+| `node_id` | String | The coordinating node ID. |
 | `source` | Object | The query source body. |
 | `indices` | Array | The list of indexes targeted by the query. |
 | `search_type` | String | The search execution type (for example, `query_then_fetch`). |

_observing-your-data/query-insights/query-insights-dashboard.md

@@ -59,7 +59,7 @@ The filters dropdown menus allow you to select the following query filters.
 | **Type**                | Filter by query type.                                               | `query`, `group`   |
 | **Indexes**             | Filter queries based on specific OpenSearch indexes.                | `index1`, `index2` |
 | **Search Type**         | Filter by search execution method.                                  | `query then fetch` |
-| **Coordinator Node ID** | Focus on queries executed by a specific coordinator node.           | `node-1`, `node-2` |
+| **Coordinating Node ID** | Focus on queries executed by a specific coordinating node.           | `node-1`, `node-2` |
 | **WLM Group**           | Filter queries by workload management group.                        | `default`          |
 | **Time Range**          | Adjust the time range for the queries displayed.                    | `last 1 day`       |
 
@@ -95,7 +95,7 @@ The top row of the panel displays P90 and P99 statistics for the following metri
 
 The **Queries by** section displays an interactive pie chart and a corresponding table that categorize query distribution by a selected dimension. You can switch between the following dimensions using the dropdown menu:
 
-- **Node** -- Groups queries by the coordinator node.
+- **Node** -- Groups queries by the coordinating node.
 - **Index** -- Groups queries by the target index.
 - **Username** -- Groups queries by the user who submitted the query.
 - **WLM Group** -- Groups queries by workload management group.
@@ -161,7 +161,7 @@ The following table provides descriptions for each metric and the metric's relat
 | **Memory Usage**        | The amount of memory used during execution.  | `Memory Usage`     | `Average Memory Usage` | `Avg Memory Usage/Memory Usage` |
 | **Indexes**             | A list of indexes involved in the query or group. | `Indexes`  | Not shown            | `Indexes`    |
 | **Search Type**         | The search execution method used (such as `query` or `fetch`).  | `Search Type`      | Not shown            | `Search Type`  |
-| **Coordinator Node ID** | The node that coordinated the query.  | `Coordinator Node ID` | Not shown         | `Coordinator Node ID` |
+| **Coordinating Node ID** | The node that coordinated the query.  | `Coordinating Node ID` | Not shown         | `Coordinating Node ID` |
 | **WLM Group**           | The workload management group associated with the query. | `WLM Group`        | Not shown            | `WLM Group`     |
 | **Total Shards**        | The number of shards involved in query processing.   | `Total Shards`     | Not shown            | `Total Shards`  |
 
@@ -182,7 +182,7 @@ You can access detailed information about a single query by selecting the query
 
 ![Individual Query Details]({{site.url}}{{site.baseurl}}/images/Query-Insights/IndividualQueryDetails.png)
 
-In the query details view, you can view information such as **Timestamp**, **CPU Time**, **Memory Usage**, **Indexes**, **Search Type**, **Coordinator Node ID**, and **Total Shards**.
+In the query details view, you can view information such as **Timestamp**, **CPU Time**, **Memory Usage**, **Indexes**, **Search Type**, **Coordinating Node ID**, and **Total Shards**.
 
 If the query source has been truncated because of size limits, it is displayed as a string instead of formatted JSON.
 
@@ -195,7 +195,7 @@ To view query group details, select a query ID marked as a "group" in the **Top
 ![Query Group Details]({{site.url}}{{site.baseurl}}/images/Query-Insights/GroupQueryDetails.png)
 
 - The **Aggregate summary for queries** section provides a view of key query metrics for the entire group, including **Average latency**, **Average CPU time**, **Average memory usage**, and **Group by** criteria.
-- The **Sample query details** section provides information about a single representative query, including its **Timestamp**, **Indexes**, **Search Type**, **Coordinator Node ID**, and **Total Shards**.
+- The **Sample query details** section provides information about a single representative query, including its **Timestamp**, **Indexes**, **Search Type**, **Coordinating Node ID**, and **Total Shards**.
 - The **Latency** section presents a graphical representation of the run phases for the query.
 
 ## Configuration

_search-plugins/async/index.md

@@ -262,5 +262,5 @@ Options | Description
 `search_failed` | The number of asynchronous search requests that completed with a failed response.
 `persisted` | The number of asynchronous search requests whose final result successfully persisted in the cluster.
 `persist_failed` | The number of asynchronous search requests whose final result failed to persist in the cluster.
-`running_current` | The number of asynchronous search requests that are running on a given coordinator node.
+`running_current` | The number of asynchronous search requests that are running on a given coordinating node.
 `cancelled` | The number of asynchronous search requests that were canceled while the search was running.

_search-plugins/async/settings.md

@@ -26,7 +26,7 @@ PUT _cluster/settings
 Setting | Default | Description
 :--- | :--- | :---
 `plugins.asynchronous_search.max_search_running_time` | 12 hours | The maximum running time for the search beyond which the search is terminated.
-`plugins.asynchronous_search.node_concurrent_running_searches` | 20 | The concurrent searches running per coordinator node.
+`plugins.asynchronous_search.node_concurrent_running_searches` | 20 | The concurrent searches running per coordinating node.
 `plugins.asynchronous_search.max_keep_alive` | 5 days | The maximum amount of time that search results can be stored in the cluster.
 `plugins.asynchronous_search.max_wait_for_completion_timeout` | 1 minute | The maximum value for the `wait_for_completion_timeout` parameter.
 `plugins.asynchronous_search.persist_search_failures` | false | Persist asynchronous search results that end with a search failure in the system index.

_search-plugins/search-pipelines/index.md

@@ -16,7 +16,7 @@ When defined, a search pipeline is an ordered list of search processors that is
 
 ![Search processor diagram]({{site.url}}{{site.baseurl}}/images/search-pipelines.png)
 
-Both request and response processing for the pipeline are performed on the coordinator node, so there is no shard-level processing.
+Both request and response processing for the pipeline are performed on the coordinating node, so there is no shard-level processing.
 {: .note}
 
 ## Search processors

_sql-and-ppl/ppl/commands/patterns.md

@@ -20,7 +20,7 @@ The `patterns` command supports the following modes:
 
 The command identifies variable parts of log messages (such as timestamps, numbers, IP addresses, and unique identifiers) and replaces them with `<*>` placeholders to create reusable patterns. For example, email addresses like `amberduke@pyrami.com` and `hattiebond@netagy.com` are replaced with the pattern `<*>@<*>.<*>`.
 
-The `patterns` command is not executed on OpenSearch data nodes. It only groups log patterns from log messages that have been returned to the coordinator node.
+The `patterns` command is not executed on OpenSearch data nodes. It only groups log patterns from log messages that have been returned to the coordinating node.
 {: .note}
 
 ## Syntax

_sql-and-ppl/ppl/commands/spath.md

@@ -13,7 +13,7 @@ The `spath` command extracts fields from structured JSON data. It operates in tw
 - **Path-based mode**: When `path` is specified, extracts a single value at the given JSON path.
 - **Auto-extract mode** (experimental): When `path` is omitted, extracts all fields from the JSON into a map.
 
-The `spath` command is not executed on OpenSearch data nodes. It extracts fields from data after it has been returned to the coordinator node, which is slow on large datasets. We recommend indexing fields needed for filtering directly instead of using `spath` to filter nested fields.
+The `spath` command is not executed on OpenSearch data nodes. It extracts fields from data after it has been returned to the coordinating node, which is slow on large datasets. We recommend indexing fields needed for filtering directly instead of using `spath` to filter nested fields.
 {: .note}
 
 ## Syntax