Merge branch 'main' into sec-rn-9.2.2

Author: benironside

.github/workflows/update-kube-stack-version.yml

@@ -36,7 +36,7 @@ jobs:
     - name: Run update script
       id: update-script
       run: |
-        echo "Running kube-stack-version update script..."
+        echo "Running version update script (kube-stack-version and helm-version)..."
         python scripts/update_kube_stack_version.py
         echo "Script completed successfully"
 
@@ -60,19 +60,22 @@ jobs:
       uses: peter-evans/create-pull-request@v7
       with:
         token: ${{ secrets.GITHUB_TOKEN }}
-        commit-message: 'chore: update kube-stack-version'
-        title: 'chore: update kube-stack-version'
+        commit-message: 'chore: update kube-stack-version and helm-version'
+        title: 'chore: update kube-stack-version and helm-version'
         body: |
-          This PR automatically updates the `kube-stack-version` in `docset.yml` based on the latest version from the elastic-agent repository.
+          This PR automatically updates the `kube-stack-version` and `helm-version` in `docset.yml` based on the latest versions from the Kibana and Elastic Agent repositories.
           
           **Changes:**
-          - Updated `kube-stack-version` to the latest value from elastic-agent repository
+          - Updated `kube-stack-version` to the latest value from the Kibana repository
+          - Updated `helm-version` to the latest value from the Elastic Agent repository
           
           **Generated by:** [Update Kube Stack Version workflow](https://github.com/${{ github.repository }}/actions/workflows/update-kube-stack-version.yml)
           
           This is an automated update. Please review the changes before merging.
         branch: update-kube-stack-version
         delete-branch: true
+        team-reviewers: |
+          ingest-docs
         labels: |
           automated
           chore
@@ -91,7 +94,7 @@ jobs:
           git diff HEAD -- docset.yml >> $GITHUB_STEP_SUMMARY
           echo '```' >> $GITHUB_STEP_SUMMARY
         else
-          echo "ℹ️ **No changes needed** - kube-stack-version is already up to date" >> $GITHUB_STEP_SUMMARY
+          echo "ℹ️ **No changes needed** - kube-stack-version and helm-version are already up to date" >> $GITHUB_STEP_SUMMARY
         fi
 
     - name: Summary
@@ -102,5 +105,5 @@ jobs:
         if [ "${{ steps.check-changes.outputs.has_changes }}" == "true" ]; then
           echo "✅ **PR Created** - Changes detected and pull request created" >> $GITHUB_STEP_SUMMARY
         else
-          echo "ℹ️ **No changes needed** - kube-stack-version is already up to date" >> $GITHUB_STEP_SUMMARY
+          echo "ℹ️ **No changes needed** - kube-stack-version and helm-version are already up to date" >> $GITHUB_STEP_SUMMARY
         fi

.gitignore

@@ -9,10 +9,10 @@
 # Add LLM/AI related files
 AGENTS.md
 .github/copilot-instructions.md
-.github/instructions/**.instructions.md
+.github/instructions
 CLAUDE.md
 GEMINI.md
 .cursor
 
 # VS code settings
-.vscode
+.vscode

deploy-manage/_snippets/autoops-callout-with-ech.md

@@ -1,5 +1,4 @@
 :::{admonition} Simplify monitoring with AutoOps
-Use AutoOps in your {{ech}}, ECE, ECK, or self-managed deployments. 
-
-AutoOps is a monitoring tool that simplifies cluster management through performance recommendations, resource utilization visibility, and real-time issue detection with resolution paths. For more information, refer to [](/deploy-manage/monitor/autoops.md).
-::::
+:applies_to: { ess:, ece:, eck:, self:, "serverless": "ga" }
+AutoOps is a monitoring tool that simplifies cluster management through performance recommendations, resource utilization visibility, and real-time issue detection with resolution paths. Learn more about [](/deploy-manage/monitor/autoops.md).
+:::

deploy-manage/_snippets/autoops-cc-ech-faq.md

@@ -1,3 +1,3 @@
 This path is not supported. Currently, we only support using Cloud Connect to connect ECE, ECK, and self-managed clusters to AutoOps.
 
-For {{ech}} clusters, AutoOps is set up and enabled automatically in all supported [regions](/deploy-manage/monitor/autoops/ec-autoops-regions.md), and can be [accessed](/deploy-manage/monitor/autoops/ec-autoops-how-to-access.md#ec-autoops-how-to-access) from the deployment overview page.
+For {{ech}} deployments, AutoOps is set up and enabled automatically in all supported [regions](/deploy-manage/monitor/autoops/ec-autoops-regions.md), and can be [accessed](/deploy-manage/monitor/autoops/ec-autoops-how-to-access.md) from the deployment overview page.

deploy-manage/api-keys/elastic-cloud-api-keys.md

@@ -34,9 +34,11 @@ These keys provides access to the API that enables you to manage your deployment
 
     ::::{note}
     When an API key is nearing expiration, Elastic sends an email to the creator of the API key and each of the operational contacts. When you use an API key to authenticate, the API response header `X-Elastic-Api-Key-Expiration` indicates the key’s expiration date. You can log this value to detect API keys that are nearing expiration.
+
+    Once an API key expires, it will automatically be removed from the API Keys tab.
     ::::
 
-5. Click **Create API key**, copy the generated API key, and store it in a safe place. You can also download the key as a CSV file.
+6. Click **Create API key**, copy the generated API key, and store it in a safe place. You can also download the key as a CSV file.
 
 The API key needs to be supplied in the `Authorization` header of a request, in the following format:
 

deploy-manage/api-keys/serverless-project-api-keys.md

@@ -14,7 +14,7 @@ In serverless projects, the following types of API keys exist:
 - **Personal** API keys, that you can create to allow external services to access your serverless project on behalf of a user.
 - **Managed** API keys, created and managed by {{kib}} to correctly run background tasks.
 
-You can manage your keys in **{{project-settings}} → {{manage-app}} → {{api-keys-app}}**:
+You can manage your keys in **{{project-settings}} → {{manage-app}} → API keys**:
 
 :::{image} /deploy-manage/images/serverless-api-key-management.png
 :alt: API keys UI
@@ -24,7 +24,7 @@ You can manage your keys in **{{project-settings}} → {{manage-app}} → {{api-
 
 ## Create an API key [api-keys-create-an-api-key]
 
-In **{{api-keys-app}}**, click **Create API key**:
+In **API keys**, click **Create API key**:
 
 :::{image} /deploy-manage/images/serverless-create-personal-api-key.png
 :alt: Create API key UI
@@ -77,11 +77,11 @@ For the `role_descriptors` object schema, check out the [`/_security/api_key` en
 
 ## Update an API key [api-keys-update-an-api-key]
 
-In **{{api-keys-app}}**, click on the name of the key. You can update only **Restrict privileges** and **Include metadata**.
+In **API keys**, click on the name of the key. You can update only **Restrict privileges** and **Include metadata**.
 
 
 ## View and delete API keys [api-keys-view-and-delete-api-keys]
 
-The **{{api-keys-app}}** app lists your API keys, including the name, date created, and status. When API keys expire, the status changes from `Active` to `Expired`.
+The **API keys** app lists your API keys, including the name, date created, and status. When API keys expire, the status changes from `Active` to `Expired`.
 
 You can delete API keys individually or in bulk.

deploy-manage/autoscaling/autoscaling-deciders.md

@@ -68,7 +68,7 @@ The estimation of expected additional data is based on past indexing that occurr
 :   (Optional, [time value](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#time-units)) The window of time to use for forecasting. Defaults to 30 minutes.
 
 
-### {{api-examples-title}} [autoscaling-proactive-storage-decider-examples]
+### Examples [autoscaling-proactive-storage-decider-examples]
 
 This example puts an autoscaling policy named `my_autoscaling_policy`, overriding the proactive decider’s `forecast_window` to be 10 minutes.
 
@@ -143,7 +143,7 @@ Both `num_anomaly_jobs_in_queue` and `num_analytics_jobs_in_queue` are designed
 :   (Optional, [time value](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#time-units)) Specifies the time to delay before scaling down. Defaults to 1 hour. If a scale down is possible for the entire time window, then a scale down is requested. If the cluster requires a scale up during the window, the window is reset.
 
 
-### {{api-examples-title}} [autoscaling-machine-learning-decider-examples]
+### Examples [autoscaling-machine-learning-decider-examples]
 
 This example creates an autoscaling policy named `my_autoscaling_policy` that overrides the default configuration of the {{ml}} decider.
 
@@ -198,7 +198,7 @@ The [autoscaling](../../deploy-manage/autoscaling.md) `fixed` decider responds w
 :   (Optional, integer) Number of nodes to use when calculating capacity. Defaults to `1`.
 
 
-### {{api-examples-title}} [autoscaling-fixed-decider-examples]
+### Examples [autoscaling-fixed-decider-examples]
 
 This example puts an autoscaling policy named `my_autoscaling_policy`, enabling and configuring the fixed decider.
 

deploy-manage/deploy/cloud-on-k8s/pod-disruption-budget.md

@@ -19,12 +19,13 @@ In {{eck}} 3.1 and earlier, all clusters follow the [default PodDisruptionBudget
 :::
 
 ## Advanced rules (Enterprise license required)
+
 ```{applies_to}
 deployment:
   eck: ga 3.2
 ```
 
-In Elasticsearch clusters managed by ECK and licensed with an Enterprise license, a separate PDB is created for each type of `nodeSet` defined in the manifest. This setup allows Kubernetes upgrade or maintenance operations to be executed more quickly. Each PDB permits one Elasticsearch Pod per `nodeSet` to be disrupted at a time, provided the Elasticsearch cluster maintains the health status described in the following table:
+In {{es}} clusters managed by ECK and licensed with an Enterprise license, PDBs are created based on {{es}} node roles, allowing Kubernetes upgrade or maintenance operations to be executed more quickly. Multiple `nodeSets` with the same roles, such as `master` or `ml`, are combined into a single PDB. Each PDB permits one {{es}} Pod to be disrupted at a time, provided the {{es}} cluster maintains the health status described in the following table.
 
 | Role | Cluster health required | Notes |
 |------|------------------------|--------|
@@ -40,6 +41,7 @@ In Elasticsearch clusters managed by ECK and licensed with an Enterprise license
 Single-node clusters are not considered highly available and can always be disrupted regardless of license type.
 
 ## Default rules (Basic license) [default-pdb-rules]
+
 :::{note}
 In {{eck}} 3.1 and earlier, all clusters follow this behavior regardless of license type.
 :::

deploy-manage/deploy/elastic-cloud/serverless.md

@@ -20,7 +20,7 @@ products:
 Serverless projects use the core components of the {{stack}}, such as {{es}} and {{kib}}, and are based on an architecture that decouples compute and storage. Search and indexing operations are separated, which offers high flexibility for scaling your workloads while ensuring a high level of performance.
 
 :::{note}
-There are differences between {{es-serverless}} and {{ech}}, for a list of differences between them, see [differences between {{ech}} and {{es-serverless}}](../elastic-cloud.md#general-what-is-serverless-elastic-differences-between-serverless-projects-and-hosted-deployments-on-ecloud).
+There are differences between {{es-serverless}} and {{ech}}. Learn more in [Compare {{ech}} and {{es-serverless}}](../elastic-cloud.md#general-what-is-serverless-elastic-differences-between-serverless-projects-and-hosted-deployments-on-ecloud).
 :::
 
 ## Get started
@@ -55,6 +55,9 @@ Afterwards, you can:
   * **Data:** Choose the data you want to ingest and the method to ingest it. By default, data is stored indefinitely in your project, and you define the retention settings for your data streams.
   * **Performance:** For granular control over costs and query performance against your project data, serverless projects come with a set of predefined settings you can edit.
 
+:::{include} /deploy-manage/_snippets/autoops-callout-with-ech.md
+:::
+
 ## Monitor serverless status [general-serverless-status]
 
 Serverless projects run on cloud platforms, which may undergo changes in availability. When availability changes, Elastic makes sure to provide you with a current service status.

deploy-manage/deploy/self-managed/air-gapped-install.md

@@ -243,7 +243,7 @@ WantedBy=default.target
 
 ## {{artifact-registry}} [air-gapped-elastic-artifact-registry]
 
-Air-gapped install of the {{artifact-registry}} is necessary in order to enable {{agent}} deployments to perform self-upgrades and install certain components which are needed for some of the data integrations (that is, in addition to what is also retrieved from the EPR). To learn more, refer to [Host your own artifact registry for binary downloads](/reference/fleet/air-gapped.md#host-artifact-registry) in the {{fleet}} and {{elastic-agent}} Guide.
+Air-gapped install of the {{artifact-registry}} is necessary in order to enable {{agent}} deployments to perform self-upgrades and install certain components which are needed for some of the data integrations (that is, in addition to what is also retrieved from the EPR). To learn more, refer to [Host your own artifact registry for binary downloads](/reference/fleet/air-gapped.md#host-artifact-registry) in the {{fleet}} and {{agent}} Guide.
 
 ::::{note}
 When setting up own web server, such as NGINX, to function as the {{artifact-registry}}, it is recommended not to use TLS as there are, currently, no direct ways to establish certificate trust between {{agents}} and this service.