Add markers for cluster APIs.

_api-reference/cluster-api/cluster-allocation.md

@@ -12,26 +12,36 @@ redirect_from:
 **Introduced 1.0**
 {: .label .label-purple }
 
-The most basic cluster allocation explain request finds an unassigned shard and explains why it can't be allocated to a node.
-
-If you add some options, you can instead get information on a specific shard, including why OpenSearch assigned it to its current node.
+The Cluster Allocation Explain API explains how shards are allocated in the cluster and why unassigned shards cannot be assigned to a node.
 
 
+<!-- spec_insert_start
+api: cluster.allocation_explain
+component: endpoints
+-->
 ## Endpoints
-
 ```json
-GET _cluster/allocation/explain
-POST _cluster/allocation/explain
+GET  /_cluster/allocation/explain
+POST /_cluster/allocation/explain
 ```
+<!-- spec_insert_end -->
+
 
+<!-- spec_insert_start
+api: cluster.allocation_explain
+columns: Parameter, Data type, Description, Default
+component: query_parameters
+-->
 ## Query parameters
 
-All parameters are optional.
+The following table lists the available query parameters. All query parameters are optional.
 
-Parameter | Type | Description
-:--- | :--- | :---
-include_yes_decisions | Boolean | OpenSearch makes a series of yes or no decisions when trying to allocate a shard to a node. If this parameter is true, OpenSearch includes the (generally more numerous) "yes" decisions in its response. Default is `false`.
-include_disk_info | Boolean | Whether to include information about disk usage in the response. Default is `false`.
+| Parameter | Data type | Description | Default |
+| :--- | :--- | :--- | :--- |
+| `include_disk_info` | Boolean | When `true`, returns information about disk usage and shard sizes. | `false` |
+| `include_yes_decisions` | Boolean | When `true`, returns any `YES` decisions in the allocation explanation. `YES` decisions indicate successful shard allocation attempts for a given node. | `false` |
+
+<!-- spec_insert_end -->
 
 
 ## Request body fields
@@ -40,10 +50,10 @@ All cluster allocation explain fields are optional.
 
 Field | Type | Description
 :--- | :--- | :---
-current_node | String | If you only want an explanation if the shard happens to be on a particular node, specify that node name here.
-index | String | The name of the shard's index.
-primary | Boolean | Whether to provide an explanation for the primary shard (true) or its first replica (false), which share the same shard ID.
-shard | Integer | The shard ID that you want an explanation for.
+`current_node` | String | Returns an explanation only if the shard is located on the `current_node`.
+`index` | String | The name of the shard's index.
+`primary` | Boolean | Whether to provide an explanation for the primary shard (`true`) or its first replica (`false`), both of which share the same shard ID.
+`shard` | Integer | The shard ID that you want an explanation for.
 
 ## Example request
 

_api-reference/cluster-api/cluster-awareness.md

@@ -15,31 +15,55 @@ redirect_from:
 
 To control the distribution of search or HTTP traffic, you can use the weights per awareness attribute to control the distribution of search or HTTP traffic across zones. This is commonly used for zonal deployments, heterogeneous instances, and routing traffic away from zones during zonal failure.
 
+<!-- spec_insert_start
+api: cluster.get_weighted_routing
+component: endpoints
+-->
 ## Endpoints
+```json
+GET /_cluster/routing/awareness/{attribute}/weights
+```
+<!-- spec_insert_end -->
 
+<!-- spec_insert_start
+api: cluster.put_weighted_routing
+component: endpoints
+omit_header: true
+-->
 ```json
-PUT /_cluster/routing/awareness/<attribute>/weights
-GET /_cluster/routing/awareness/<attribute>/weights?local
-GET /_cluster/routing/awareness/<attribute>/weights
+PUT /_cluster/routing/awareness/{attribute}/weights
 ```
+<!-- spec_insert_end -->
 
+<!-- spec_insert_start
+api: cluster.put_weighted_routing
+component: path_parameters
+-->
 ## Path parameters
 
-Parameter | Type | Description
-:--- | :--- | :---
-attribute | String | The name of the awareness attribute, usually `zone`. The attribute name must match the values listed in the request body when assigning weights to zones.
+The following table lists the available path parameters.
+
+| Parameter | Required | Data type | Description |
+| :--- | :--- | :--- | :--- |
+| `attribute` | **Required** | String | The name of awareness attribute, usually `zone`. |
+
+<!-- spec_insert_end -->
+
 
 ## Request body fields
 
+The following table lists the available request body fields.
+
 Parameter | Type | Description
 :--- | :--- | :---
-weights | JSON object | Assigns weights to attributes within the request body of the PUT request. Weights can be set in any ratio, for example, 2:3:5. In a 2:3:5 ratio with 3 zones, for every 100 requests sent to the cluster, each zone would receive either 20, 30, or 50 search requests in a random order. When assigned a weight of `0`, the zone does not receive any search traffic. 
-_version | String | Implements optimistic concurrency control (OCC) through versioning. The parameter uses simple versioning, such as `1`, and increments upward based on each subsequent modification. This allows any servers from which a request originates to validate whether or not a zone has been modified. 
+`weights` | JSON object | Assigns weights to attributes within the request body of the PUT request. Weights can be set in any ratio, for example, 2:3:5. In a 2:3:5 ratio with 3 zones, for every 100 requests sent to the cluster, each zone would receive either 20, 30, or 50 search requests in a random order. When assigned a weight of `0`, the zone does not receive any search traffic. 
+`_version` | String | Implements optimistic concurrency control (OCC) through versioning. The parameter uses simple versioning, such as `1`, and increments upward based on each subsequent modification. This allows any servers from which a request originates to validate whether or not a zone has been modified. 
 
 
 In the following example request body, `zone_1` and `zone_2` receive 50 requests each, whereas `zone_3` is prevented from receiving requests:
 
-```
+```json
+PUT /_cluster/routing/awareness/zone/weights
 { 
       "weights":
       {
@@ -50,14 +74,14 @@ In the following example request body, `zone_1` and `zone_2` receive 50 requests
       "_version" : 1
 }
 ```
+{% include copy-curl.html %}
 
 ## Example requests
 
 ### Weighted round robin search
 
 The following example request creates a round robin shard allocation for search traffic by using an undefined ratio:
 
-
 ```json
 PUT /_cluster/routing/awareness/zone/weights
 { 
@@ -117,6 +141,7 @@ OpenSearch responds with the weight of each zone:
       },
       "_version":1
 }
+```
 
 
 ## Next steps

_api-reference/cluster-api/cluster-component-template.md

@@ -0,0 +1,142 @@
+---
+layout: default
+title: Cluster component template
+nav_order: 25
+parent: Cluster APIs
+---
+
+# Cluster component template
+**Introduced 1.0**
+{: .label .label-purple }
+
+The Cluster Component Template API creates or updates the cluster's component templates.
+
+# Endpoints
+
+The `GET` method returns one or more component templates:
+
+<!-- spec_insert_start
+api: cluster.get_component_template
+component: endpoints
+omit_header: true
+-->
+```json
+GET /_component_template
+GET /_component_template/{name}
+```
+<!-- spec_insert_end -->
+
+The `EXISTS` method returns information about whether a component template exists:
+
+<!-- spec_insert_start
+api: cluster.exists_component_template
+component: endpoints
+omit_header: true
+-->
+```json
+HEAD /_component_template/{name}
+```
+<!-- spec_insert_end -->
+
+The `PUT` method creates or updates a component template:
+
+<!-- spec_insert_start
+api: cluster.put_component_template
+component: endpoints
+omit_header: true
+-->
+```json
+POST /_component_template/{name}
+PUT  /_component_template/{name}
+```
+<!-- spec_insert_end -->
+
+The `DELETE` method deletes a component template:
+
+<!-- spec_insert_start
+api: cluster.delete_component_template
+component: endpoints
+omit_header: true
+-->
+```json
+DELETE /_component_template/{name}
+```
+<!-- spec_insert_end -->
+
+<!-- spec_insert_start
+api: cluster.put_component_template
+component: path_parameters
+-->
+## Path parameters
+
+The following table lists the available path parameters.
+
+| Parameter | Required | Data type | Description |
+| :--- | :--- | :--- | :--- |
+| `name` | **Required** | String | The name of the component template to create. OpenSearch includes the following built-in component templates: `logs-mappings`, `logs-settings`, `metrics-mappings`, `metrics-settings`, `synthetics-mapping`, and `synthetics-settings`. OpenSearch uses these templates to configure backing indexes for its data streams. If you want to overwrite one of these templates, set the replacement template `version` to a higher value than the current version. If you want to disable all built-in component and index templates, set `stack.templates.enabled` to `false` using the [Cluster Settings API]({{site.url}}{{site.baseurl}}/api-reference/cluster-api/cluster-settings/). |
+
+<!-- spec_insert_end -->
+
+<!-- spec_insert_start
+api: cluster.put_component_template
+columns: Parameter, Data type, Description, Default
+include_deprecated: false
+component: query_parameters
+-->
+## Query parameters
+
+The following table lists the available query parameters. All query parameters are optional.
+
+| Parameter | Data type | Description | Default |
+| :--- | :--- | :--- | :--- |
+| `cluster_manager_timeout` | String | The amount of time to wait for a response from the cluster manager node. For more information about supported time units, see [Common parameters]({{site.url}}{{site.baseurl}}/api-reference/common-parameters/#time-units). | N/A |
+| `create` | Boolean | When `true`, this request cannot replace or update existing component templates. | `false` |
+| `timeout` | String | A duration. Units can be `nanos`, `micros`, `ms` (milliseconds), `s` (seconds), `m` (minutes), `h` (hours) and `d` (days). Also accepts `0` without a unit and `-1` to indicate an unspecified value. | N/A |
+
+<!-- spec_insert_end -->
+
+## Example request
+
+```json
+POST /_component_template/logs_template
+{
+  "template": {
+    "settings": {
+      "number_of_shards": 1,
+      "number_of_replicas": 1
+    },
+    "mappings": {
+      "properties": {
+        "timestamp": {
+          "type": "date"
+        },
+        "message": {
+          "type": "text"
+        },
+        "level": {
+          "type": "keyword"
+        },
+        "service": {
+          "type": "keyword"
+        }
+      }
+    },
+    "aliases": {
+      "logs_alias": {}
+    }
+  },
+  "version": 1,
+  "meta": {
+    "description": "Component template for log data"
+  }
+}
+```
+{% include copy-curl.html %}
+
+## Example response 
+
+```json
+{
+  "acknowledged": true
+}
+```

_api-reference/cluster-api/cluster-decommission.md

@@ -13,25 +13,55 @@ redirect_from:
 **Introduced 1.0**
 {: .label .label-purple }
 
-The cluster decommission operation adds support decommissioning based on awareness. It greatly benefits multi-zone deployments, where awareness attributes, such as `zones`, can aid in applying new upgrades to a cluster in a controlled fashion. This is especially useful during outages, in which case, you can decommission the unhealthy zone to prevent replication requests from stalling and prevent your request backlog from becoming too large.
+The Cluster Decommission API adds support decommissioning based on awareness. It greatly benefits multi-zone deployments, where awareness attributes, such as `zones`, can aid in applying new upgrades to a cluster in a controlled fashion. This is especially useful during outages, in which case, you can decommission the unhealthy zone to prevent replication requests from stalling and prevent your request backlog from becoming too large.
 
 For more information about allocation awareness, see [Shard allocation awareness]({{site.url}}{{site.baseurl}}//opensearch/cluster/#shard-allocation-awareness).
 
 
+<!-- spec_insert_start
+api: cluster.get_decommission_awareness
+component: endpoints
+-->
 ## Endpoints
+```json
+GET /_cluster/decommission/awareness/{awareness_attribute_name}/_status
+```
+<!-- spec_insert_end -->
 
+<!-- spec_insert_start
+api: cluster.put_decommission_awareness
+component: endpoints
+omit_header: true
+-->
+```json
+PUT /_cluster/decommission/awareness/{awareness_attribute_name}/{awareness_attribute_value}
+```
+<!-- spec_insert_end -->
+
+<!-- spec_insert_start
+api: cluster.delete_decommission_awareness
+component: endpoints
+omit_header: true
+-->
 ```json
-PUT  /_cluster/decommission/awareness/{awareness_attribute_name}/{awareness_attribute_value}
-GET  /_cluster/decommission/awareness/{awareness_attribute_name}/_status
 DELETE /_cluster/decommission/awareness
 ```
+<!-- spec_insert_end -->
 
+<!-- spec_insert_start
+api: cluster.put_decommission_awareness
+component: path_parameters
+-->
 ## Path parameters
 
-Parameter | Type | Description
-:--- | :--- | :---
-awareness_attribute_name | String | The name of awareness attribute, usually `zone`.
-awareness_attribute_value | String | The value of the awareness attribute. For example, if you have shards allocated in two different zones, you can give each zone a value of `zone-a` or `zoneb`. The cluster decommission operation decommissions the zone listed in the method.
+The following table lists the available path parameters.
+
+| Parameter | Required | Data type | Description |
+| :--- | :--- | :--- | :--- |
+| `awareness_attribute_name` | **Required** | String | The name of the awareness attribute. |
+| `awareness_attribute_value` | **Required** | String | The value of the awareness attribute. For example, if you have shards allocated in two different zones, you can give each zone a value of `zone-a` or `zoneb`. The cluster decommission operation decommissions the zone listed in the method. |
+
+<!-- spec_insert_end -->
 
 ## Example requests