Merge branch 'main' into api-basics

Author: lcawl

deploy-manage/security/fips-ingest.md

@@ -85,14 +85,23 @@ When you use {{agent}} and {{fleet-server}}, these limitations apply:
 * Running {{agent}} in [OpenTelemetry mode](https://github.com/elastic/elastic-agent/blob/main/internal/pkg/otel/README.md) is not yet supported. This includes all receivers, such as Filebeat Receiver, Metricbeat Receiver, [Prometheus Receiver](https://www.elastic.co/docs/reference/integrations/prometheus).
 * Some Elastic Integrations are not FIPS compatible, as they depend on functionality that is not yet supported for FIPS configuration. In general, when using {{agent}} and {{fleet-server}}, the same restrictions listed previously for {{metricbeat}} and {{filebeat}} modules, inputs, and processors apply.
 
-  These Elastic Integrations have components that are **not** FIPS compatible, and **cannot** be used in FIPS environments, even if combined with other ingest tools that offer FIPS mode. 
-
-  - [Azure Logs Integration (v2 preview)](integration-docs://reference/azure/events.md)
-  - [Azure Event Hub Input](integration-docs://reference/azure/eventhub.md)
-  - [SQL Input](integration-docs://reference/sql.md) 
-  - [PostgreSQL Integration](integration-docs://reference/postgresql.md)
-  - [MongoDB Integration](integration-docs://reference/mongodb.md)
-  - [MySQL Integration](integration-docs://reference/mysql.md)
-  - [Microsoft SQL Server Integration](integration-docs://reference/microsoft_sqlserver.md)
-  - [Oracle Integration](integration-docs://reference/oracle.md)
-
+### Elastic Integrations that are not FIPS compatible [ingest-limitations-integrations]
+
+These Elastic Integrations have components that are **not** FIPS compatible, and **cannot** be used in FIPS environments, even if combined with other ingest tools that offer FIPS mode. 
+
+- [Azure Logs Integration (v2 preview)](integration-docs://reference/azure/events.md)
+- [Azure Event Hub Input](integration-docs://reference/azure/eventhub.md)
+- [Azure AI Foundry Integration](integration-docs://reference/azure_ai_foundry.md)
+- [Azure App Service Integration](integration-docs://reference/azure_app_service.md)
+- [Azure Application Insights Integration](integration-docs://reference/azure_application_insights.md)
+- [Azure Billing Metrics Integration](integration-docs://reference/azure_billing.md)
+- [Azure Functions Integration](integration-docs://reference/azure_functions.md)
+- [Custom Azure Logs Integration](integration-docs://reference/azure_logs.md)
+- [Azure Resource Metrics Integration](integration-docs://reference/azure_metrics.md)
+- [Azure OpenAI Integration](integration-docs://reference/azure_openai.md)
+- [SQL Input](integration-docs://reference/sql.md) 
+- [PostgreSQL Integration](integration-docs://reference/postgresql.md)
+- [MongoDB Integration](integration-docs://reference/mongodb.md)
+- [MySQL Integration](integration-docs://reference/mysql.md)
+- [Microsoft SQL Server Integration](integration-docs://reference/microsoft_sqlserver.md)
+- [Oracle Integration](integration-docs://reference/oracle.md)

deploy-manage/upgrade/orchestrator/upgrade-cloud-on-k8s.md

@@ -101,8 +101,11 @@ This will update the ECK installation to the latest binary and update the CRDs a
 Upgrading the operator results in a one-time update to existing managed resources in the cluster. This potentially triggers a rolling restart of pods by Kubernetes to apply those changes. The following list contains the ECK operator versions that would cause a rolling restart after they have been installed.
 
 ```
-1.6, 1.9, 2.0, 2.1, 2.2, 2.4, 2.5, 2.6, 2.7, 2.8, 2.14
+1.6, 1.9, 2.0, 2.1, 2.2, 2.4, 2.5, 2.6, 2.7, 2.8, 2.14, 3.1 <1>
 ```
+
+1. The restart when upgrading to version 3.1 happens only for applications using [stack monitoring](/deploy-manage/monitor/stack-monitoring/eck-stack-monitoring.md).
+
 ::::{note}
 Stepping over one of these versions, for example, upgrading ECK from 2.6 to 2.9, still triggers a rolling restart.
 ::::

manage-data/ingest/transform-enrich/readable-maintainable-ingest-pipelines.md

@@ -1,4 +1,3 @@
-
 ---
 mapped_pages:
   - https://www.elastic.co/docs/manage-data/ingest/transform-enrich/common-mistakes.html

manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md

@@ -48,11 +48,11 @@ Tp complete the migration with minimal downtime, use incremental snapshots. Whil
 
 1. **09:00**: Take the initial full snapshot of the old cluster. You can also take the initial full snapshot the day before.
 2. **09:30**: Restore the snapshot to the new cluster.
-3. **09:55**: Take another snapshot of the old cluster and restore it to the new cluster. Repeat this process until the snapshot and restore operations take only a few seconds or minutes.
+3. **09:55**: Take another snapshot of the old cluster and restore it to the new cluster. Repeat this process until the snapshot and restore operations take only a few seconds or minutes. Remember that when restoring indices that _already_ exist in the new cluster (for example, to pull in recently copied data), they first need to be [closed](/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md#considerations). Also, remember that the restore operation automatically opens indices, so you will likely need to close the actively written ones after restoring them.
 4. **10:15**: Perform the final cutover.
     1. In the old cluster, pause indexing or set indices to read-only. For details on setting indices to read-only to safely pause indexing during migration, check [Index lifecycle actions: Read-only](elasticsearch://reference/elasticsearch/index-lifecycle-actions/ilm-readonly.md).
     2. Take a final snapshot. 
-    3. Restore the snapshot to the new cluster. 
+    3. Restore the snapshot to the new cluster. Again, remember that to restore indices that already exist, they first need to be closed.
     4. Change ingestion and querying to the new cluster. 
     5. Open the indices in the new cluster. 
 

reference/fleet/add-fleet-server-kubernetes.md

@@ -336,7 +336,7 @@ Adapt and change the suggested manifests and deployment strategy to your needs,
           automountServiceAccountToken: false
           containers:
           - name: elastic-agent
-            image: docker.elastic.co/beats/elastic-agent:{{version.stack}}
+            image: docker.elastic.co/elastic-agent:{{version.stack}}
             env:
               - name: FLEET_SERVER_ENABLE
                 value: "true"
@@ -422,7 +422,7 @@ Adapt and change the suggested manifests and deployment strategy to your needs,
           automountServiceAccountToken: false
           containers:
           - name: elastic-agent
-            image: docker.elastic.co/beats/elastic-agent:{{version.stack}}
+            image: docker.elastic.co/elastic-agent:{{version.stack}}
             env:
               - name: FLEET_SERVER_ENABLE
                 value: "true"

release-notes/elastic-cloud-serverless/known-issues.md

@@ -51,7 +51,7 @@ After you complete this step, risk scores should automatically begin to successf
 
 ## Resolved
 
-:::{dropdown} In {{sec-serverless}}, installing an {{elastic-defend}} integration or a new agent policy upgrades installed prebuilt rules, reverting user customizations and overwriting user-added actions and exceptions
+:::{dropdown} Installing the {{elastic-defend}} integration or a new agent policy in {{sec-serverless}} forces an upgrade of prebuilt rules
 
 On April 10, 2025, it was discovered that when you install a new {{elastic-defend}} integration or agent policy, the installed prebuilt detection rules upgrade to their latest versions (if any new versions are available). The upgraded rules lose any user-added rule actions, exceptions, and customizations.