Merge branch 'main' into IPL-8491

sandrampeter · web-flow · commit f953aa823471 · 2025-09-09T17:55:42.000-04:00
diff --git a/content/terraform-enterprise/1.0.x/docs/enterprise/deploy/manage/upgrade.mdx b/content/terraform-enterprise/1.0.x/docs/enterprise/deploy/manage/upgrade.mdx
@@ -21,6 +21,8 @@ Complete the following steps to upgrade Terraform Enterprise:
 
 1. If your deployment is configured to run multiple `terraform-enterprise` nodes, scale down to a single node. You can run multiple nodes when Terraform Enterprise is in `active-active` mode. Refer to  [Configure the operational mode](/terraform/enterprise/deploy/configuration/storage/configure-mode) for additional information.
 
+1. If your deployment makes use of an autoscaling group to manage instances of Terraform Enterprise, disable any configured health checks that would trigger the autoscaling group to rotate Terraform Enterprise instances during an upgrade.
+
 1. Stop the Terraform Enterprise application.
 
   <Tabs>
diff --git a/content/terraform-enterprise/v202501-1/docs/enterprise/deploy/manage/upgrade.mdx b/content/terraform-enterprise/v202501-1/docs/enterprise/deploy/manage/upgrade.mdx
@@ -21,6 +21,8 @@ Complete the following steps to upgrade Terraform Enterprise:
 
 1. If your deployment is configured to run multiple `terraform-enterprise` nodes, scale down to a single node. You can run multiple nodes when Terraform Enterprise is in `active-active` mode. Refer to  [Configure the operational mode](/terraform/enterprise/deploy/configuration/storage/configure-mode) for additional information.
 
+1. If your deployment makes use of an autoscaling group to manage instances of Terraform Enterprise, disable any configured health checks that would trigger the autoscaling group to rotate Terraform Enterprise instances during an upgrade.
+
 1. Stop the Terraform Enterprise application.
 
   <Tabs>
diff --git a/content/terraform-enterprise/v202502-1/docs/enterprise/deploy/manage/upgrade.mdx b/content/terraform-enterprise/v202502-1/docs/enterprise/deploy/manage/upgrade.mdx
@@ -21,6 +21,8 @@ Complete the following steps to upgrade Terraform Enterprise:
 
 1. If your deployment is configured to run multiple `terraform-enterprise` nodes, scale down to a single node. You can run multiple nodes when Terraform Enterprise is in `active-active` mode. Refer to  [Configure the operational mode](/terraform/enterprise/deploy/configuration/storage/configure-mode) for additional information.
 
+1. If your deployment makes use of an autoscaling group to manage instances of Terraform Enterprise, disable any configured health checks that would trigger the autoscaling group to rotate Terraform Enterprise instances during an upgrade.
+
 1. Stop the Terraform Enterprise application.
 
   <Tabs>
diff --git a/content/terraform-enterprise/v202502-2/docs/enterprise/deploy/manage/upgrade.mdx b/content/terraform-enterprise/v202502-2/docs/enterprise/deploy/manage/upgrade.mdx
@@ -21,6 +21,8 @@ Complete the following steps to upgrade Terraform Enterprise:
 
 1. If your deployment is configured to run multiple `terraform-enterprise` nodes, scale down to a single node. You can run multiple nodes when Terraform Enterprise is in `active-active` mode. Refer to  [Configure the operational mode](/terraform/enterprise/deploy/configuration/storage/configure-mode) for additional information.
 
+1. If your deployment makes use of an autoscaling group to manage instances of Terraform Enterprise, disable any configured health checks that would trigger the autoscaling group to rotate Terraform Enterprise instances during an upgrade.
+
 1. Stop the Terraform Enterprise application.
 
   <Tabs>
diff --git a/content/terraform-enterprise/v202503-1/docs/enterprise/deploy/manage/upgrade.mdx b/content/terraform-enterprise/v202503-1/docs/enterprise/deploy/manage/upgrade.mdx
@@ -21,6 +21,8 @@ Complete the following steps to upgrade Terraform Enterprise:
 
 1. If your deployment is configured to run multiple `terraform-enterprise` nodes, scale down to a single node. You can run multiple nodes when Terraform Enterprise is in `active-active` mode. Refer to  [Configure the operational mode](/terraform/enterprise/deploy/configuration/storage/configure-mode) for additional information.
 
+1. If your deployment makes use of an autoscaling group to manage instances of Terraform Enterprise, disable any configured health checks that would trigger the autoscaling group to rotate Terraform Enterprise instances during an upgrade.
+
 1. Stop the Terraform Enterprise application.
 
   <Tabs>
diff --git a/content/terraform-enterprise/v202504-1/docs/enterprise/deploy/manage/upgrade.mdx b/content/terraform-enterprise/v202504-1/docs/enterprise/deploy/manage/upgrade.mdx
@@ -21,6 +21,8 @@ Complete the following steps to upgrade Terraform Enterprise:
 
 1. If your deployment is configured to run multiple `terraform-enterprise` nodes, scale down to a single node. You can run multiple nodes when Terraform Enterprise is in `active-active` mode. Refer to  [Configure the operational mode](/terraform/enterprise/deploy/configuration/storage/configure-mode) for additional information.
 
+1. If your deployment makes use of an autoscaling group to manage instances of Terraform Enterprise, disable any configured health checks that would trigger the autoscaling group to rotate Terraform Enterprise instances during an upgrade.
+
 1. Stop the Terraform Enterprise application.
 
   <Tabs>
diff --git a/content/terraform-enterprise/v202505-1/docs/enterprise/deploy/manage/upgrade.mdx b/content/terraform-enterprise/v202505-1/docs/enterprise/deploy/manage/upgrade.mdx
@@ -21,6 +21,8 @@ Complete the following steps to upgrade Terraform Enterprise:
 
 1. If your deployment is configured to run multiple `terraform-enterprise` nodes, scale down to a single node. You can run multiple nodes when Terraform Enterprise is in `active-active` mode. Refer to  [Configure the operational mode](/terraform/enterprise/deploy/configuration/storage/configure-mode) for additional information.
 
+1. If your deployment makes use of an autoscaling group to manage instances of Terraform Enterprise, disable any configured health checks that would trigger the autoscaling group to rotate Terraform Enterprise instances during an upgrade.
+
 1. Stop the Terraform Enterprise application.
 
   <Tabs>
diff --git a/content/terraform-enterprise/v202506-1/docs/enterprise/deploy/manage/upgrade.mdx b/content/terraform-enterprise/v202506-1/docs/enterprise/deploy/manage/upgrade.mdx
@@ -21,6 +21,8 @@ Complete the following steps to upgrade Terraform Enterprise:
 
 1. If your deployment is configured to run multiple `terraform-enterprise` nodes, scale down to a single node. You can run multiple nodes when Terraform Enterprise is in `active-active` mode. Refer to  [Configure the operational mode](/terraform/enterprise/deploy/configuration/storage/configure-mode) for additional information.
 
+1. If your deployment makes use of an autoscaling group to manage instances of Terraform Enterprise, disable any configured health checks that would trigger the autoscaling group to rotate Terraform Enterprise instances during an upgrade.
+
 1. Stop the Terraform Enterprise application.
 
   <Tabs>
diff --git a/content/terraform-enterprise/v202507-1/docs/enterprise/deploy/manage/upgrade.mdx b/content/terraform-enterprise/v202507-1/docs/enterprise/deploy/manage/upgrade.mdx
@@ -21,6 +21,8 @@ Complete the following steps to upgrade Terraform Enterprise:
 
 1. If your deployment is configured to run multiple `terraform-enterprise` nodes, scale down to a single node. You can run multiple nodes when Terraform Enterprise is in `active-active` mode. Refer to  [Configure the operational mode](/terraform/enterprise/deploy/configuration/storage/configure-mode) for additional information.
 
+1. If your deployment makes use of an autoscaling group to manage instances of Terraform Enterprise, disable any configured health checks that would trigger the autoscaling group to rotate Terraform Enterprise instances during an upgrade.
+
 1. Stop the Terraform Enterprise application.
 
   <Tabs>
diff --git a/content/vault/v1.19.x/content/docs/auth/ldap.mdx b/content/vault/v1.19.x/content/docs/auth/ldap.mdx
@@ -184,6 +184,8 @@ Use `vault path-help` for more details.
 The root bindpass can be rotated to a Vault-generated value that is not accessible by the operator.
 This will ensure that only Vault is able to access the "root" user that Vault uses to manipulate credentials.
 
+Vault logs manual root rotations to `vault.log` with a note that the rotation was `on user request`.
+
 ```shell-session
 vault write -f auth/ldap/config/rotate-root
 ```
@@ -231,6 +233,8 @@ TTL.
 For more details on rotating root credentials in the Azure plugin, refer to the
 [Root credential rotation](/vault/api-docs/auth/ldap#rotate-root) API docs.
 
+@include 'rotation-manager-logging.mdx'
+
 ## Examples:
 
 ### Scenario 1
diff --git a/content/vault/v1.19.x/content/docs/secrets/databases/index.mdx b/content/vault/v1.19.x/content/docs/secrets/databases/index.mdx
@@ -104,7 +104,7 @@ TTL.
 For more details on rotating root credentials in the DB Secrets engine, refer to the
 [Rotate Root credentials](/vault/api-docs/secret/databases#rotate-root-credentials) API docs.
 
-
+@include 'rotation-manager-logging.mdx'
 
 ## Setup
 
@@ -296,6 +296,8 @@ or otherwise, it will not be rotated until the next scheduled rotation.
 !> The `rotation_period` and `rotation_schedule` fields are
 mutually exclusive. One of them must be set but not both.
 
+Vault logs rotations with reference to the `name` of the role and `error` if the rotation failed. The logs also indicate if the rotation was part of a `periodic function`.
+
 ## Password generation
 
 Passwords are generated via [Password Policies](/vault/docs/concepts/password-policies).
diff --git a/content/vault/v1.19.x/content/docs/secrets/ldap.mdx b/content/vault/v1.19.x/content/docs/secrets/ldap.mdx
@@ -158,6 +158,8 @@ TTL.
 For more details on rotating root credentials in the Azure plugin, refer to the
 [Root credential rotation](/vault/api-docs/secret/ldap#rotate-root) API docs.
 
+@include 'rotation-manager-logging.mdx'
+
 ## Static credentials
 
 ### Setup
@@ -194,11 +196,17 @@ role, the response will include the time before the next rotation (`ttl`).
 The `binddn` account used by Vault should be rotated using the `rotate-root` endpoint to generate a password
 only Vault will know.
 
+As with the rotation manager, Vault logs rotations with reference to the
+`name` of the role and `error` if the rotation failed. The logs also indicate
+ if the rotation was part of a `periodic function`.
+
 ### Manual rotation
 
 Static roles can be manually rotated using the `rotate-role` endpoint. When manually
 rotated the rotation period will start over.
 
+Logging for manual rotation records the same information as other rotation logging with an additional reference that the rotation happened `on user request`.
+
 ### Deleting static roles
 
 Passwords are not rotated upon deletion of a static role. The password should be manually
diff --git a/content/vault/v1.19.x/content/partials/rotation-manager-logging.mdx b/content/vault/v1.19.x/content/partials/rotation-manager-logging.mdx
@@ -0,0 +1,12 @@
+### Rotation logging
+
+The rotation manager emits logs to the standard `vault.log` on any successful or
+failed rotation.
+
+In the case of success, Vault notes:
+
+- the rotated credential as the first parameter, `rotationID`.
+- the anticipated time of the next rotation as `expire_time`.
+
+In the case of failure, Vault sets `rotationID` to `err` and may emit additional
+logs depending on the configured log level.
diff --git a/content/vault/v1.20.x/content/docs/auth/ldap.mdx b/content/vault/v1.20.x/content/docs/auth/ldap.mdx
@@ -198,6 +198,8 @@ This will ensure that only Vault is able to access the "root" user that Vault us
 vault write -f auth/ldap/config/rotate-root
 ```
 
+Vault logs manual root rotations to `vault.log` with a note that the rotation was `on user request`.
+
 ### Schedule-based root credential rotation
 
 @include 'alerts/enterprise-only.mdx'
@@ -241,6 +243,8 @@ TTL.
 For more details on rotating root credentials in the Azure plugin, refer to the
 [Root credential rotation](/vault/api-docs/auth/ldap#rotate-root) API docs.
 
+@include rotation-manager-logging.mdx
+
 ## Examples:
 
 ### Scenario 1
diff --git a/content/vault/v1.20.x/content/docs/secrets/databases/index.mdx b/content/vault/v1.20.x/content/docs/secrets/databases/index.mdx
@@ -105,6 +105,8 @@ TTL.
 For more details on rotating root credentials in the DB Secrets engine, refer to the
 [Rotate Root credentials](/vault/api-docs/secret/databases#rotate-root-credentials) API docs.
 
+@include 'rotation-manager-logging.mdx'
+
 ## Setup
 
 Most secrets engines must be configured in advance before they can perform their
@@ -397,6 +399,8 @@ or otherwise, it will not be rotated until the next scheduled rotation.
 !> The `rotation_period` and `rotation_schedule` fields are
 mutually exclusive. One of them must be set but not both.
 
+Vault logs rotations with reference to the `name` of the role and `error` if the rotation failed. The logs also indicate if the rotation was part of a `periodic function`.
+
 ## Password generation
 
 Passwords are generated via [Password Policies](/vault/docs/concepts/password-policies).
diff --git a/content/vault/v1.20.x/content/docs/secrets/ldap.mdx b/content/vault/v1.20.x/content/docs/secrets/ldap.mdx
@@ -155,9 +155,11 @@ of the root credential until the field is reset to `false`. If you use
 `rotation_period`, setting `disable_automated_rotation` also resets the credential
 TTL.
 
-For more details on rotating root credentials in the Azure plugin, refer to the
+For more details on rotating root credentials in the LDAP plugin, refer to the
 [Root credential rotation](/vault/api-docs/secret/ldap#rotate-root) API docs.
 
+@include 'rotation-manager-logging.mdx'
+
 ## Static credentials
 
 ### Setup
@@ -194,11 +196,17 @@ role, the response will include the time before the next rotation (`ttl`).
 The `binddn` account used by Vault should be rotated using the `rotate-root` endpoint to generate a password
 only Vault will know.
 
+As with the rotation manager, Vault logs rotations with reference to the
+`name` of the role and `error` if the rotation failed. The logs also indicate
+ if the rotation was part of a `periodic function`.
+
 ### Manual rotation
 
 Static roles can be manually rotated using the `rotate-role` endpoint. When manually
 rotated the rotation period will start over.
 
+Logging for manual rotation records the same information as other rotation logging with an additional reference that the rotation happened `on user request`.
+
 ### Deleting static roles
 
 Passwords are not rotated upon deletion of a static role. The password should be manually
diff --git a/content/vault/v1.20.x/content/partials/rotation-manager-logging.mdx b/content/vault/v1.20.x/content/partials/rotation-manager-logging.mdx
@@ -0,0 +1,12 @@
+### Rotation logging
+
+The rotation manager emits logs to the standard `vault.log` on any successful or
+failed rotation.
+
+In the case of success, Vault notes:
+
+- the rotated credential as the first parameter, `rotationID`.
+- the anticipated time of the next rotation as `expire_time`.
+
+In the case of failure, Vault sets `rotationID` to `err` and may emit additional
+logs depending on the configured log level.
