Merge branch 'main' into ece-4.0.1-bump

Author: kilfoyle

deploy-manage/deploy/cloud-enterprise/ece-manage-capacity.md

@@ -31,23 +31,26 @@ ECE does not support hot-adding of resources to a running node.  When increasing
 ::::
 
 
-To adjust the allocator capacity, prior to ECE 3.5.0; it is necessary to reinstall ECE on the host with a new value assigned to the `--capacity` parameter. From ECE 3.5.0 onwards, just use the ECE API :
+To adjust the allocator capacity prior to ECE 3.5.0, you must reinstall ECE on the host with a new value assigned to the `--capacity` parameter. Starting with ECE 3.5.0, you can update the allocator capacity using the [allocator settings ECE API](https://www.elastic.co/docs/api/doc/cloud-enterprise/operation/operation-set-allocator-settings). After making this change, you must restart the allocator service for it to take effect.
 
 ```sh
 curl -X PUT \
   http(s)://<ece_admin_url:port>/api/v1/platform/infrastructure/allocators/<allocator_id>/settings \
-  -H “Authorization: ApiKey $ECE_API_KEY” \
+  -H “Authorization: ApiKey $ECE_API_KEY” \ <1>
   -H 'Content-Type: application/json' \
   -d '{"capacity":<Capacity_Value_in_MB>}'
 ```
-
-For more information on how to use API keys for authentication, check the section [Access the API from the Command Line](cloud://reference/cloud-enterprise/ece-api-command-line.md).
+1. For information on how to use API keys for authentication, refer to [Access the API from the command line](cloud://reference/cloud-enterprise/ece-api-command-line.md).
 
 ::::{important}
-Prior to ECE 3.5.0, regardless of the use of this API, the [CPU quota](#ece-alloc-cpu) used the memory specified at installation time.
+When running ECE on Podman, CPU quotas for existing instances cannot be disabled or updated. As a result, changing an allocator’s capacity won’t affect the CPU quotas of already running containers.
 ::::
 
+After applying the change, log in to the allocator host you updated and restart the allocator service:
 
+```sh
+docker restart frc-allocators-allocator
+```
 
 ### Examples [ece_examples]
 
@@ -67,6 +70,9 @@ ECE uses CPU quotas to assign shares of the allocator host to the instances that
 
 `CPU quota = DeploymentRAM / HostCapacity`
 
+::::{important}
+In ECE versions prior to 3.5.0, the CPU quota is always calculated using the memory specified at installation time, even if you later update the host capacity using the API.
+::::
 
 ### Examples [ece_examples_2]
 

deploy-manage/deploy/cloud-enterprise/resource-overrides.md

@@ -10,7 +10,9 @@ products:
 
 # Resource overrides [ece-resource-overrides]
 
-{{ecloud}} allocators assign resources to {{es}} instances based on RAM, where RAM is proportional to CPU and disk resources. As needed, you can temporarily override the allocated resources to stabilize the deployment. You should reset overrides as soon as possible, or make the override permanent by [changing your configuration](working-with-deployments.md).
+{{ecloud}} allocators assign resources to {{es}} instances based on RAM, where RAM is proportional to CPU and disk resources. As needed, you can temporarily override the allocated resources to stabilize the deployment. To do this, use the contextual menu available on each instance in the deployment UI.
+
+Overrides are intended to be temporary and may be lost after making configuration changes to the deployment. You should reset overrides as soon as possible, or make them permanent by [changing your configuration](./configure-deployment.md).
 
 The RAM to CPU proportions can’t be overridden per instance.
 
@@ -31,3 +33,35 @@ Overriding the instance size restarts the {{es}} node.
 ::::
 
 When an instance within a deployment has resource overrides, it displays a warning banner reading **Elastic added temporary capacity to stabilize the deployment**. [Configuration changes](working-with-deployments.md) can still be safely submitted.
+
+## Disabling CPU quotas at deployment level [cpu-hard-limit]
+
+In addition to overriding resources for individual instances, you can also completely disable CPU limits for your deployment from the **Operations** page of each deployment.
+
+::::{note}
+When running ECE on Podman, CPU quotas for existing instances cannot be removed or updated. As a result, disabling the CPU hard limit has no effect on Podman-based allocators.
+::::
+
+::::{important}
+Disabling the CPU hard limit for an entire deployment is an advanced action and should be approached with caution. This setting removes CPU quotas from the containers, which means some instances could consume excessive CPU resources and degrade the performance of other instances running on the same allocators.
+
+We strongly recommend making this change only under the guidance of Elastic Support, and only as a temporary measure or for troubleshooting purposes.
+::::
+
+To disable CPU limits of your deployment instances, choose one of the following methods:
+
+* Open the **Operations** page of the deployment UI, and select **Turn off** in the **CPU hard limit** section.
+
+* Use the [advanced editor](./advanced-cluster-configuration.md), and in the **{{es}} cluster data** section, look for the following setting:
+
+  ```yaml
+        "resources": {
+          "cpu": {
+            "hard_limit": false
+          }
+        }
+  ```
+
+  Set `hard_limit` to `false` to disable CPU limits, or to `true` to enforce strict CPU limits (default behavior).
+
+This change doesn’t require a restart of the deployment.

deploy-manage/deploy/elastic-cloud/differences-from-other-elasticsearch-offerings.md

@@ -34,6 +34,7 @@ The information below reflects our strategic goals, plans and objectives and inc
 | **User management** | Elastic Cloud-managed and deployment-local users | Elastic Cloud-managed users only. Serverless users are managed at the organization level with SAML authentication support. |
 | **Backups** | User-managed with Snapshot & Restore | Automatically backed up by Elastic |
 | **Solutions** | Full {{stack}} per deployment | Single solution per project |
+| **Cross-origin resource sharing (CORS)** | Supported | Not available. Browser-based applications must route requests through a backend proxy server. |
 
 In Serverless, Elastic automatically manages:
 * Cluster scaling and optimization

deploy-manage/monitor/stack-monitoring/collecting-monitoring-data-with-elastic-agent.md

@@ -36,8 +36,8 @@ To collect {{es}} monitoring data, add an {{es}} integration to an {{agent}} and
 
 5. Configure the integration name and optionally add a description. Make sure you configure all required settings:
 
-    1. Under **Collect {{es}} logs**, modify the log paths to match your {{es}} environment.
-    2. Under **Collect {{es}} metrics**, make sure the hosts setting points to your {{es}} host URLs. By default, the integration collects {{es}} monitoring metrics from `localhost:9200`. If that host and port number are not correct, update the `hosts` setting. If you configured {{es}} to use encrypted communications, you must access it via HTTPS. For example, use a `hosts` setting like `https://localhost:9200`.
+    1. Under **Logs**, modify the log paths to match your {{es}} environment.
+    2. Under **Metrics (Stack Monitoring)**, make sure the hosts setting points to your {{es}} host URLs. By default, the integration collects {{es}} monitoring metrics from `localhost:9200`. If that host and port number are not correct, update the `hosts` setting. If you configured {{es}} to use encrypted communications, you must access it via HTTPS. For example, use a `hosts` setting like `https://localhost:9200`.
     3. Expand **Advanced options**. If the Elastic {{security-features}} are enabled, enter the username and password of a user that has the `remote_monitoring_collector` role.
     4. Specify the scope:
 

deploy-manage/monitor/stack-monitoring/kibana-monitoring-elastic-agent.md

@@ -19,7 +19,7 @@ To learn about monitoring in general, refer to [](/deploy-manage/monitor/stack-m
 
 ## Prerequisites [_prerequisites]
 
-* [Set up {{es}} monitoring](/deploy-manage/monitor/stack-monitoring/elasticsearch-monitoring-self-managed.md) and optionally [create a monitoring cluster](/deploy-manage/monitor/stack-monitoring/es-self-monitoring-prod.md). 
+* [Set up {{es}} monitoring](/deploy-manage/monitor/stack-monitoring/elasticsearch-monitoring-self-managed.md) and optionally [create a monitoring cluster](/deploy-manage/monitor/stack-monitoring/es-self-monitoring-prod.md).
 * Create a user on the production cluster that has the `remote_monitoring_collector` [built-in role](../../users-roles/cluster-or-deployment-auth/built-in-roles.md).
 
 
@@ -43,8 +43,8 @@ To collect {{kib}} monitoring data, add a {{kib}} integration to an {{agent}} an
 
 5. Configure the integration name and optionally add a description. Make sure you configure all required settings:
 
-    * Under **Collect {{kib}} logs**, modify the log paths to match your {{kib}} environment.
-    * Under **Collect {{kib}} metrics**, make sure the hosts setting points to your {{kib}} host URLs. By default, the integration collects {{kib}} monitoring metrics from `localhost:5601`. If that host and port number are not correct, update the `hosts` setting. If you configured {{kib}} to use encrypted communications, you must access it via HTTPS. For example, use a `hosts` setting like `https://localhost:5601`.
+    * Under **Logs**, modify the log paths to match your {{kib}} environment.
+    * Under **Metrics (Stack Monitoring)**, make sure the hosts setting points to your {{kib}} host URLs. By default, the integration collects {{kib}} monitoring metrics from `localhost:5601`. If that host and port number are not correct, update the `hosts` setting. If you configured {{kib}} to use encrypted communications, you must access it via HTTPS. For example, use a `hosts` setting like `https://localhost:5601`.
     * If the Elastic {{security-features}} are enabled, expand **Advanced options** under the Hosts setting and enter the username and password of a user that has the `remote_monitoring_collector` role.
 
 6. Choose where to add the integration policy. Click **New hosts** to add it to new agent policy or **Existing hosts** to add it to an existing agent policy.

deploy-manage/toc.yml

@@ -79,7 +79,6 @@ toc:
                   - file: deploy/cloud-enterprise/ece-load-balancers.md
                   - file: deploy/cloud-enterprise/ece-jvm.md
                   - file: deploy/cloud-enterprise/ece-wildcard-dns.md
-                  - file: deploy/cloud-enterprise/ece-manage-capacity.md
               - file: deploy/cloud-enterprise/install.md
                 children:
                   - file: deploy/cloud-enterprise/identify-deployment-scenario.md
@@ -128,6 +127,7 @@ toc:
                   - file: deploy/cloud-enterprise/change-ece-api-url.md
                   - file: deploy/cloud-enterprise/change-endpoint-urls.md
                   - file: deploy/cloud-enterprise/enable-custom-endpoint-aliases.md
+                  - file: deploy/cloud-enterprise/ece-manage-capacity.md
                   - file: deploy/cloud-enterprise/configure-allocator-affinity.md
                   - file: deploy/cloud-enterprise/change-allocator-disconnect-timeout.md
                   - file: deploy/cloud-enterprise/manage-elastic-stack-versions.md

deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md

@@ -169,7 +169,7 @@ This realm has a few mandatory settings, and a number of optional settings. The
 1. Set the `Client Secret` that was assigned to the RP during registration in the OP.  To set the client secret, add the `xpack.security.authc.realms.oidc.<oidc1>.rp.client_secret` setting [to the {{es}} keystore](/deploy-manage/security/secure-settings.md).
 
 :::{warning}
-In {{ech}} and {{ece}}, after you configure Client Secret, any attempt to restart the deployment will fail until you complete the rest of the configuration steps. If you want to roll back the Active Directory realm configurations, you need to remove the `xpack.security.authc.realms.oidc.oidc1.rp.client_secret` that was just added.
+In {{ech}} and {{ece}}, after you configure Client Secret, any attempt to restart the deployment will fail until you complete the rest of the configuration steps. If you want to roll back the OpenID Connect realm configurations, you need to remove the `xpack.security.authc.realms.oidc.oidc1.rp.client_secret` that was just added.
 :::
 
 ::::{note}