Merge branch 'main' into autoops-serverless-docs

Author: wajihaparvez

deploy-manage/kibana-reporting-configuration.md

@@ -36,6 +36,11 @@ Before upgrading {{kib}} in a production environment, we encourage you to test y
 
 To secure {{report-features}}, you must grant users access to reporting functionality and protect the reporting endpoints with TLS/SSL encryption. Additionally, you can install graphical packages on the operating system to enable screenshot capabilities in the {{kib}} server.
 
+:::{note}
+:applies_to: {stack: ga, serverless: unavailable}
+API keys are used to authenticate requests to generate reports. If you have a cross-cluster search environment and want to generate reports from remote clusters, you must have the appropriate cluster and index privileges on the remote cluster and local cluster. For example, if requests are authenticated with an API key, the API key requires certain privileges on the local cluster that contains the leader index, instead of the remote. For more information and examples, refer to [Configure roles and users for remote clusters](../deploy-manage/remote-clusters/remote-clusters-cert.md#remote-clusters-privileges-cert).
+:::
+
 Configuring reporting in your environment involves two main areas:
 
 ### Granting users access to {{report-features}}

deploy-manage/monitor/autoops/cc-connect-self-managed-to-autoops.md

@@ -157,8 +157,7 @@ With this authentication method, you need to create an API key to grant access t
 
 ```
 5. Select **Create API key**.
-6. When prompted to copy the key, select **Beats** from the dropdown.
-7. Copy the key and save it for later. You will need it when you [install the agent](#install-agent). 
+6. Copy the key and save it for later. You will need it when you [install the agent](#install-agent).
 
 ::::
 

deploy-manage/monitor/autoops/ec-autoops-regions.md

@@ -29,27 +29,27 @@ AutoOps for {{ECH}} is currently available in the following regions for AWS:
 
 | Region | Name |
 | --- | --- | --- | --- |
-| us-east-1 | N. Virginia |
-| us-east-2 | Ohio |
-| us-west-1 | N. California |
-| us-west-2 | Oregon |
-| ca-central-1 | Canada |
-| eu-west-1 | Ireland |
-| eu-west-2 | London |
-| eu-west-3 | Paris |
-| eu-north-1 | Stockholm |
-| eu-central-1 | Frankfurt |
-| eu-central-2 | Zurich |
-| eu-south-1 | Milan |
-| me-south-1 | Bahrain |
-| ap-east-1 | Hong Kong |
-| ap-northeast-1 | Tokyo |
-| ap-northeast-2 | Seoul |
-| ap-southeast-1 | Singapore |
-| ap-southeast-2 | Sydney |
-| ap-south-1 | Mumbai |
-| sa-east-1 | Sao Paulo |
-| af-south-1 | Cape Town |
+| us-east-1 | US East (N. Virginia) |
+| us-east-2 | US East (Ohio) |
+| us-west-1 | US West (N. California) |
+| us-west-2 | US West (Oregon) |
+| ca-central-1 | Canada (Central) |
+| eu-west-1 | Europe (Ireland) |
+| eu-west-2 | Europe (London) |
+| eu-west-3 | Europe (Paris) |
+| eu-north-1 | Europe (Stockholm) |
+| eu-central-1 | Europe (Frankfurt) |
+| eu-central-2 | Europe (Zurich) |
+| eu-south-1 | Europe (Milan) |
+| me-south-1 | Middle East (Bahrain) |
+| ap-east-1 | Asia Pacific (Hong Kong) |
+| ap-northeast-1 | Asia Pacific (Tokyo) |
+| ap-northeast-2 | Asia Pacific (Seoul) |
+| ap-southeast-1 | Asia Pacific (Singapore) |
+| ap-southeast-2 | Asia Pacific (Sydney) |
+| ap-south-1 | Asia Pacific (Mumbai) |
+| sa-east-1 | South America (Sao Paulo) |
+| af-south-1 | Africa (Cape Town) |
 
 Regions for Azure and GCP are coming soon.
 
@@ -59,10 +59,10 @@ AutoOps for serverless projects is currently available in the following regions
 
 | Region | Name |
 | --- | --- | --- | --- |
-| us-east-1 | N. Virginia |
-| eu-west-1 | Ireland |
-| ap-southeast-1 | Singapore |
-| us-west-2 | Oregon |
+| us-east-1 | US East (N. Virginia) |
+| eu-west-1 | Europe (Ireland) |
+| ap-southeast-1 | Asia Pacific (Singapore) |
+| us-west-2 | US West (Oregon) |
 
 The only exception is the **Search AI Lake** view, which is available in all CSP regions across AWS, Azure, and GCP.
 

deploy-manage/toc.yml

@@ -812,7 +812,7 @@ toc:
           - file: upgrade/prepare-to-upgrade/upgrade-assistant.md
       - file: upgrade/deployment-or-cluster.md
         children:
-          - hidden: upgrade/deployment-or-cluster/upgrade-717.md
+          - file: upgrade/deployment-or-cluster/upgrade-717.md
           - file: upgrade/deployment-or-cluster/upgrade-on-ech.md
           - file: upgrade/deployment-or-cluster/upgrade-on-ece.md
           - file: upgrade/deployment-or-cluster/upgrade-on-eck.md

deploy-manage/tools/snapshot-and-restore/_snippets/restore-snapshot-common-prerequisites.md

@@ -0,0 +1,6 @@
+* To use {{kib}}'s **Snapshot and Restore** feature, you must have the following permissions:
+
+    * [Cluster privileges](elasticsearch://reference/elasticsearch/security-privileges.md#privileges-list-cluster): `monitor`, `manage_slm`, `cluster:admin/snapshot`, and `cluster:admin/repository`
+    * [Index privilege](elasticsearch://reference/elasticsearch/security-privileges.md#privileges-list-indices): `monitor` privilege on all the indices
+
+* To register a snapshot repository or restore a snapshot, the cluster’s global metadata must be writeable. Ensure there aren’t any [cluster blocks](elasticsearch://reference/elasticsearch/configuration-reference/miscellaneous-cluster-settings.md#cluster-read-only) that prevent write access. The restore operation ignores index blocks.

deploy-manage/tools/snapshot-and-restore/elastic-cloud-hosted.md

@@ -26,12 +26,8 @@ From within {{ech}}, you can restore a snapshot from a different deployment in t
 
 ## Prerequisites for {{ech}}
 
-To use Kibana's Snapshot and Restore feature, you must have the following permissions:
-
-- Cluster privileges: `monitor`, `manage_slm`, `cluster:admin/snapshot`, and `cluster:admin/repository`
-- Index privilege: `all` on the monitor index
-
-To register a snapshot repository, the cluster’s global metadata must be writable. Ensure there aren’t any cluster blocks that prevent write access.
+:::{include} _snippets/restore-snapshot-common-prerequisites.md
+:::
 
 ## Considerations
 

deploy-manage/tools/snapshot-and-restore/restore-snapshot.md

@@ -27,12 +27,11 @@ In this guide, you’ll learn how to:
 This guide also provides tips for [restoring to another cluster](#restore-different-cluster) and [troubleshooting common restore errors](#troubleshoot-restore).
 
 ## Prerequisites
-- To use Kibana’s Snapshot and Restore feature, you must have the following permissions:
-  - [Cluster privileges](elasticsearch://reference/elasticsearch/security-privileges.md#privileges-list-cluster): `monitor`, `manage_slm`, `cluster:admin/snapshot`, and `cluster:admin/repository`
-  - [Index privilege](elasticsearch://reference/elasticsearch/security-privileges.md#privileges-list-indices): `all` on the monitor index
+:::{include} _snippets/restore-snapshot-common-prerequisites.md
+:::
+
 - You can only restore a snapshot to a running cluster with an elected [master node](/deploy-manage/distributed-architecture/clusters-nodes-shards/node-roles.md#master-node-role). The snapshot’s repository must be registered and available to the cluster.
 - The snapshot and cluster versions must be compatible. See [Snapshot compatibility](/deploy-manage/tools/snapshot-and-restore.md#snapshot-compatibility).
-- To restore a snapshot, the cluster’s global metadata must be writable. Ensure there aren’t any cluster blocks that prevent writes. The restore operation ignores index blocks.
 - Before you restore a data stream, ensure the cluster contains a [matching index template](/manage-data/use-case-use-elasticsearch-to-manage-time-series-data.md#create-ts-index-template) with data stream enabled. To check, use [Kibana’s Index Management](/manage-data/data-store/index-basics.md#index-management-manage-index-templates) feature or the get index template API:
 
   ```console

deploy-manage/tools/snapshot-and-restore/searchable-snapshots.md

@@ -13,7 +13,7 @@ products:
 
 # Searchable snapshots [searchable-snapshots]
 ::::{important}
-Searchable snapshots is a feature that requires an Enteprise license. 
+Searchable snapshots is a feature that requires an Enterprise license. 
 ::::
 
 {{search-snaps-cap}} let you use [snapshots](../snapshot-and-restore.md) to search infrequently accessed and read-only data in a very cost-effective fashion. The [cold](../../../manage-data/lifecycle/data-tiers.md#cold-tier) and [frozen](../../../manage-data/lifecycle/data-tiers.md#frozen-tier) data tiers use {{search-snaps}} to reduce your storage and operating costs.

deploy-manage/tools/snapshot-and-restore/self-managed.md

@@ -21,12 +21,8 @@ In this guide, you’ll learn how to:
 
 ## Prerequisites [snapshot-repo-prereqs]
 
-* To use {{kib}}'s **Snapshot and Restore** feature, you must have the following permissions:
-
-    * [Cluster privileges](elasticsearch://reference/elasticsearch/security-privileges.md#privileges-list-cluster): `monitor`, `manage_slm`, `cluster:admin/snapshot`, and `cluster:admin/repository`
-    * [Index privilege](elasticsearch://reference/elasticsearch/security-privileges.md#privileges-list-indices): `all` on the `monitor` index
-
-* To register a snapshot repository, the cluster’s global metadata must be writeable. Ensure there aren’t any [cluster blocks](elasticsearch://reference/elasticsearch/configuration-reference/miscellaneous-cluster-settings.md#cluster-read-only) that prevent write access.
+:::{include} _snippets/restore-snapshot-common-prerequisites.md
+:::
 
 ## Considerations [snapshot-repo-considerations]
 

deploy-manage/upgrade.md

@@ -48,6 +48,10 @@ Upgrading your Elastic cluster or deployment involves several stages, including
 
 - [Upgrade ingest components](./upgrade/ingest-components.md): Covers supporting components such as {{beats}}, {{agent}}, {{ls}}, and APM Server.
 
+:::{note}
+If you’re still running {{stack}} version 7.17 or earlier, refer to the [Upgrade from 7.17 guide](/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md) for detailed guidance on planning and executing the upgrade to the latest {{version.stack}} release.
+:::
+
 Additionally, if you're using a self-managed orchestration platform such as {{ece}} or {{eck}}, refer to [Upgrade your ECE or ECK orchestrator](/deploy-manage/upgrade/orchestrator.md) to keep the orchestrator up to date.
 
 ## Availability during upgrades
@@ -97,3 +101,12 @@ If you're upgrading to the current {{version.stack}} release from an earlier 8.x
 For flexible upgrade scheduling, 8.19 {{agent}}, {{beats}}, and {{ls}} are compatible with all 9.x versions of {{es}}.
 
 By default, 8.x {{es}} clients are compatible with 9.x and use [REST API compatibility](elasticsearch://reference/elasticsearch/rest-apis/compatibility.md) to maintain compatibility with the 9.x cluster.
+
+### Upgrade paths from 7.17 [upgrade-paths-7.x]
+
+Upgrading from {{stack}} version 7.17 to the latest {{version.stack}} release involves two major upgrades:
+
+- From 7.17 to 8.19
+- From 8.19 to {{version.stack}}
+
+For detailed guidance on planning and executing these upgrades, refer to the [Upgrade from 7.17 guide](/deploy-manage/upgrade/deployment-or-cluster/upgrade-717.md).