Merge branch 'elastic:main' into add-semantic-text-index-options-examples

Author: ctindel

deploy-manage/deploy/cloud-enterprise/configure-host-rhel.md

@@ -99,26 +99,26 @@ Verify that required traffic is allowed. Check the [Networking prerequisites](ec
 
     * For Podman 5
 
-        * Install the latest available version of Podman `5.2.2` using dnf.
+        * Install the latest available version `5.*` using dnf.
 
             :::{note}
-            Podman versions `5.2.2-11` and `5.2.2-13` are affected by a known [memory leak issue](https://github.com/containers/podman/issues/25473). To avoid this bug, use a later build of `5.2.2`, such as `5.2.2-16` or newer. Refer to the official [Support matrix](https://www.elastic.co/support/matrix#elastic-cloud-enterprise) for more information.
+            Podman versions `5.2.2-11` and `5.2.2-13` are affected by a known [memory leak issue](https://github.com/containers/podman/issues/25473). To avoid this bug, use a later version. Refer to the official [Support matrix](https://www.elastic.co/support/matrix#elastic-cloud-enterprise) for more information.
             :::
 
             ```sh
-            sudo dnf install podman-5.2.2 podman-remote-5.2.2
+            sudo dnf install podman-5.* podman-remote-5.*
             ```
-        * To prevent automatic Podman updates to unsupported versions, configure the Podman version to be locked at version `5.2.2`.
+        * To prevent automatic Podman major version updates, configure the Podman version to be locked at version `5.*` while still allowing minor and patch updates.
 
             ```sh
             ## Install versionlock
             sudo dnf install 'dnf-command(versionlock)'
 
             ## Lock major version
-            sudo dnf versionlock add --raw 'podman-5.2.2'
-            sudo dnf versionlock add --raw 'podman-remote-5.2.2'
+            sudo dnf versionlock add --raw 'podman-5.*'
+            sudo dnf versionlock add --raw 'podman-remote-5.*'
 
-            ## Verify that podman-5.2.2 and podman-remote-5.2.2 appear in the output
+            ## Verify that podman-5.* and podman-remote-5.* appear in the output
             sudo dnf versionlock list
             ```
 

deploy-manage/deploy/cloud-enterprise/migrate-ece-to-podman-hosts.md

@@ -129,27 +129,27 @@ Using Docker or Podman as container runtime is a configuration local to the host
 
     * For Podman 5
 
-        * Install the latest available version of Podman `5.2.2` using dnf.
+        * Install the latest available version `5.*` using dnf.
 
             :::{note}
-            Podman versions `5.2.2-11` and `5.2.2-13` are affected by a known [memory leak issue](https://github.com/containers/podman/issues/25473). To avoid this bug, use a later build of `5.2.2`, such as `5.2.2-16` or newer. Refer to the official [Support matrix](https://www.elastic.co/support/matrix#elastic-cloud-enterprise) for more information.
+            Podman versions `5.2.2-11` and `5.2.2-13` are affected by a known [memory leak issue](https://github.com/containers/podman/issues/25473). To avoid this bug, use a later version. Refer to the official [Support matrix](https://www.elastic.co/support/matrix#elastic-cloud-enterprise) for more information.
             :::
 
             ```sh
-            sudo dnf install podman-5.2.2 podman-remote-5.2.2
+            sudo dnf install podman-5.* podman-remote-5.*
             ```
 
-        * To prevent automatic Podman updates to unsupported versions, configure the Podman version to be locked at version `5.2.2`.
+        * To prevent automatic Podman major version updates, configure the Podman version to be locked at version `5.*` while still allowing minor and patch updates.
 
             ```sh
             ## Install versionlock
             sudo dnf install 'dnf-command(versionlock)'
 
             ## Lock major version
-            sudo dnf versionlock add --raw 'podman-5.2.2'
-            sudo dnf versionlock add --raw 'podman-remote-5.2.2'
+            sudo dnf versionlock add --raw 'podman-5.*'
+            sudo dnf versionlock add --raw 'podman-remote-5.*'
 
-            ## Verify that podman-5.2.2 and podman-remote-5.2.2 appear in the output
+            ## Verify that podman-5.* and podman-remote-5.* appear in the output
             sudo dnf versionlock list
             ```
 

deploy-manage/deploy/cloud-enterprise/migrate-to-podman-5.md

@@ -13,21 +13,21 @@ This guide describes the supported ways to upgrade or migrate your {{ece}} (ECE)
 
 * **Grow-and-shrink upgrade**: [Add new hosts](./install-ece-on-additional-hosts.md) running the desired Podman version to your ECE installation, then [remove the old ones](/deploy-manage/uninstall/uninstall-elastic-cloud-enterprise.md). This method is safer and preferred, as it avoids potential risks associated with upgrading the container engine or the operating system in place.
 
-ECE only supports Podman 5 in version `5.2.2`, regardless of your upgrade method. Later versions such as `5.2.3` and above are not supported. Refer always to the official [Support matrix](https://www.elastic.co/support/matrix#elastic-cloud-enterprise) for details on supported versions.
+ECE supports Podman 5, regardless of your upgrade method. Refer to the official [Support matrix](https://www.elastic.co/support/matrix#elastic-cloud-enterprise) for details on supported versions.
 
 :::{important}
-Podman versions `5.2.2-11` and `5.2.2-13` are affected by a known [memory leak issue](https://github.com/containers/podman/issues/25473). To avoid this issue, use a later build such as `5.2.2-16` or newer. 
+Podman versions `5.2.2-11` and `5.2.2-13` are affected by a known [memory leak issue](https://github.com/containers/podman/issues/25473). To avoid this issue, use a later Podman version. 
 :::
 
 The following table summarizes the supported upgrade paths to Podman 5 in ECE.
 
-| **From ↓** ...       **To →**           | Podman 5.2.2-latest | Podman 5.2.3 |
-|-----------------------------------------|-----------------|--------------|
-| **<vanilla Linux installation> (grow)** | ✓               | X            |
-| **Docker (grow-and-shrink)**            | ✓               | X            |
-| **Podman 4.9.4 (grow-and-shrink)**      | ✓               | X            |
-| **Podman 4.9.4 (in-place)**             | ✓               | X            |
-| **Podman 5.2.2 (grow-and-shrink)**      | ✓               | X            |
-| **Podman 5.2.2 (in-place)**             | ✓               | X            |
+| **From ↓** ...       **To →**           | Podman 5 |
+|-----------------------------------------|-----------------|
+| **<vanilla Linux installation> (grow)** | ✓               |
+| **Docker (grow-and-shrink)**            | ✓               |
+| **Podman 4.9.4 (grow-and-shrink)**      | ✓               |
+| **Podman 4.9.4 (in-place)**             | ✓               |
+| **Podman 5.2.2 (grow-and-shrink)**      | ✓               |
+| **Podman 5.2.2 (in-place)**             | ✓               |
 
 As shown in the table above, [migrations from Docker](./migrate-ece-to-podman-hosts.md) are only supported using the grow-and-shrink method.

deploy-manage/deploy/cloud-on-k8s/elasticsearch-deployment-quickstart.md

@@ -148,5 +148,5 @@ In order to make requests to the [{{es}} API](elasticsearch://reference/elastics
 This completes the quickstart of deploying an {{es}} cluster. We recommend continuing to:
 
 * [Deploy a {{kib}} instance](kibana-instance-quickstart.md)
-* For information about how to apply changes to your deployments, refer to [aplying updates](./update-deployments.md).
+* For information about how to apply changes to your deployments, refer to [applying updates](./update-deployments.md).
 * To explore other configuration options for your {{es}} cluster, see [](./elasticsearch-configuration.md) and [](./configure-deployments.md).

deploy-manage/deploy/cloud-on-k8s/managing-deployments-using-helm-chart.md

@@ -144,10 +144,7 @@ kind: Ingress
 metadata:
   name: elasticsearch
   labels:
-    helm.sh/chart: eck-elasticsearch-0.14.1
-    app.kubernetes.io/name: eck-elasticsearch
-    app.kubernetes.io/instance: es-kb-quickstart
-    app.kubernetes.io/managed-by: Helm
+    ...
 spec:
   rules:
   - host: "elasticsearch.example.com"
@@ -167,10 +164,7 @@ kind: Ingress
 metadata:
   name: es-kb-quickstart-eck-kibana
   labels:
-    helm.sh/chart: eck-kibana-0.14.1
-    app.kubernetes.io/name: eck-kibana
-    app.kubernetes.io/instance: es-kb-quickstart
-    app.kubernetes.io/managed-by: Helm
+    ...
 spec:
   rules:
   - host: "kibana.example.com"

deploy-manage/tools/cross-cluster-replication.md

@@ -2,11 +2,8 @@
 mapped_pages:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/xpack-ccr.html
 applies_to:
-  deployment:
-    eck:
-    ess:
-    ece:
-    self:
+  stack: ga
+  serverless: unavailable
 products:
   - id: elasticsearch
 ---

docset.yml

@@ -276,7 +276,7 @@ subs:
   agent-pull:   "https://github.com/elastic/elastic-agent/pull/"
   es-pull:   "https://github.com/elastic/elasticsearch/pull/"
   kib-pull:   "https://github.com/elastic/kibana/pull/"
-  eck_helm_minimum_version: "3.2.0"
+  eck_helm_minimum_version: 3.2.0
   eck_resources_list: "Elasticsearch, Kibana, APM Server, Beats, Elastic Agent, Elastic Maps Server, and Logstash"
   eck_resources_list_short: "APM Server, Beats, Elastic Agent, Elastic Maps Server, and Logstash"
   heroku: "Elasticsearch Add-on for Heroku"

redirects.yml

@@ -206,7 +206,7 @@ redirects:
   'troubleshoot/elasticsearch/elasticsearch-client-net-api/logging.md': 'troubleshoot/elasticsearch/clients.md'
   'troubleshoot/elasticsearch/elasticsearch-client-net-api/net.md': 'troubleshoot/elasticsearch/clients.md'
   'troubleshoot/elasticsearch/elasticsearch-client-ruby-api/ruby.md': 'troubleshoot/elasticsearch/clients.md'
-  'solutions/observability/get-started/add-data-from-splunk.md': 'solutions/observability/get-started/other-tutorials/add-data-from-splunk.md'
+  'solutions/observability/get-started/add-data-from-splunk.md': 'solutions/observability/get-started.md'
   'solutions/observability/get-started/create-an-observability-project.md': 'solutions/observability/get-started.md'
   'solutions/observability/get-started/get-started-with-dashboards.md': 'solutions/observability/get-started.md'
 # Related to https://github.com/elastic/docs-content/pull/1329
@@ -586,4 +586,7 @@ redirects:
   'deploy-manage/monitor/autoops/cc-cloud-connect-autoops-faq.md': 'deploy-manage/monitor/autoops/ec-autoops-faq.md'
 
 # Related to https://github.com/elastic/docs-team/issues/104
-  'solutions/observability/get-started/what-is-elastic-observability': 'solutions/observability.md'
+  'solutions/observability/get-started/what-is-elastic-observability': 'solutions/observability.md'
+
+# Related to https://github.com/elastic/docs-content/pull/3808
+  'solutions/observability/get-started/other-tutorials/add-data-from-splunk.md': 'solutions/observability/get-started.md'

reference/fleet/migrate-elastic-agent.md

@@ -179,7 +179,6 @@ After the restart, {{integrations-server}} will enroll a new {{agent}} for the {
 ::::
 
 
-
 ### Confirm your policy settings [migrate-elastic-agent-confirm-policy]
 
 Now that the {{fleet}} settings are correctly set up, it pays to ensure that the {{agent}} policy is also correctly pointing to the correct entities.
@@ -200,7 +199,6 @@ If you modified the {{fleet-server}} and the output in place these would have be
 ::::
 
 
-
 ## Agent policies in the new target cluster [migrate-elastic-agent-migrated-policies]
 
 By creating the new target cluster from a snapshot, all of your policies should have been created along with all of the agents. These agents will be offline due to the fact that the actual agents are not checking in with the new, target cluster (yet) and are still communicating with the source cluster.
@@ -210,7 +208,11 @@ The agents can now be re-enrolled into these policies and migrated over to the n
 
 ## Migrate {{agent}}s to the new target cluster [migrate-elastic-agent-migrated-agents]
 
-In order to ensure that all required API keys are correctly created, the agents in your current cluster need to be re-enrolled into the new, target cluster.
+::::{note}
+Agents to be migrated cannot be tamper-protected or running as a {{fleet-server}}.
+::::
+
+In order to ensure that all required API keys are correctly created, the agents in your current cluster need to be re-enrolled into the new target cluster.
 
 This is best performed one policy at a time. For a given policy, you need to capture the enrollment token and the URL for the agent to connect to. You can find these by running the in-product steps to add a new agent.
 
@@ -224,27 +226,43 @@ This is best performed one policy at a time. For a given policy, you need to cap
     :screenshot:
     :::
 
-5. On the host machines where the current agents are installed, enroll the agents again using this copied URL and the enrollment token:
+5. Choose an approach:
 
-    ```shell
-    sudo elastic-agent enroll --url=<fleet server url> --enrollment-token=<token for the new policy>
-    ```
+    ::::{tab-set}
+    :::{tab-item} Fleet UI
 
-    The command output should be like the following:
+    {applies_to}`stack: ga 9.2` Migrate remote agents directly from the {{fleet}} UI:
 
-    :::{image} images/migrate-agent-install-command-output.png
-    :alt: Install command output
-    :screenshot:
+    1. In the source cluster, select the agents you want to migrate. Click the three dots next to the agents, and select **Migrate agents**.
+    2. In the migration dialog, provide the URI and enrollment token you obtained from the target cluster.
+    3. Use `replace_token` (Optional): When you are migrating a single agent, you can use the `replace_token` field to preserve the agent's original ID from the source cluster. This step helps with event matching, but will cause the migration to fail if the target cluster already has an agent with the same ID.
     :::
 
-6. The agent on each host will now check into the new {{fleet-server}} and appear in the new target cluster. In the source cluster, the agents will go offline as they won’t be sending any check-ins.
+    :::{tab-item} Command line
 
-    :::{image} images/migrate-agent-newly-enrolled-agents.png
-    :alt: Newly enrolled agents in the target cluster
-    :screenshot:
-    :::
+    Run the `enroll` command on each individual host:
+
+   1. On the host machines where the current agents are installed, enroll the agents again using the URL and enrollment token you obtained from the target cluster:
+
+       ```shell
+       sudo elastic-agent enroll --url=<fleet server url> --enrollment-token=<token for the new policy>
+        ```
+
+        The command output should resemble this:
+
+       :::{image} images/migrate-agent-install-command-output.png
+       :alt: Install command output
+        :screenshot:
+       :::
+
+     2. The agent on each host will now check into the new {{fleet-server}} and appear in the new target cluster. In the source cluster, the agents will go offline as they won’t be sending any check-ins.
 
-7. Repeat this procedure for each {{agent}} policy.
+        :::{image} images/migrate-agent-newly-enrolled-agents.png
+        :alt: Newly enrolled agents in the target cluster
+        :screenshot:
+        :::
 
-If all has gone well, you’ve successfully migrated your {{fleet}}-managed {{agent}}s to a new cluster.
+     3. Repeat this procedure for each {{agent}} policy.
+     :::
+     ::::