Merge pull request #303867 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: Taojunshen

articles/app-service/includes/configure-azure-storage/azure-storage-linux-container-pivot.md

@@ -225,6 +225,7 @@ To validate that the Azure Storage is mounted successfully for the app:
 ### Troubleshooting
 
 - The mount directory in the custom container should be empty. Any content stored at this path is deleted when the Azure Storage is mounted, if you specify a directory under */home*, for example. If you migrate files for an existing app, make a backup of the app and its content before you begin.
+- When mounting an NFS share, you'll need to ensure that Secure Transfer Required is disabled on the storage account. App Service doesn't support mounting NFS shares when this is enabled. It uses port 2409 and virtual network integration and private endpoints as the security measure.
 - If you delete an Azure Storage account, container, or share, remove the corresponding storage mount configuration in the app to avoid possible error scenarios.
 - We don't recommend that you use storage mounts for local databases, such as SQLite, or for any other applications and components that rely on file handles and locks.
 - Ensure the following ports are open when using virtual network integration: Azure Files: 80 and 445. Azure Blobs: 80 and 443.

articles/azure-functions/opentelemetry-howto.md

@@ -68,7 +68,7 @@ Create specific application settings in your function app based on the OpenTelem
 **[OTEL_EXPORTER_OTLP_HEADERS](functions-app-settings.md#otel_exporter_otlp_headers)**: (Optional) list of headers to apply to all outgoing data. This setting is used by many endpoints to pass an API key.
 
 ::: zone pivot="programming-language-python"
-**[PYTHON_ENABLE_OPENTELEMETRY](./functions-app-settings.md#python_applicationinsights_enable_telemetry)**: set to `true` so that the Functions host allows the Java worker process to stream OpenTelemetry logs directly, which prevents duplicate host-level entries.
+**[PYTHON_ENABLE_OPENTELEMETRY](./functions-app-settings.md#python_applicationinsights_enable_telemetry)**: set to `true` so that the Functions host allows the Python worker process to stream OpenTelemetry logs directly, which prevents duplicate host-level entries.
 ::: zone-end
 
 If your endpoint requires you to set other environment variables, you need to also add them to your application settings. For more information, see the [OTLP Exporter Configuration documentation](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/). 

articles/operator-nexus/concepts-cluster-deployment-overview.md

@@ -5,7 +5,7 @@ author: sbatchu
 ms.author: sbatchu
 ms.service: azure-operator-nexus
 ms.topic: conceptual
-ms.date: 06/07/2024
+ms.date: 08/05/2024
 ms.custom: template-concept
 ---
 
@@ -20,6 +20,13 @@ During the cluster deployment, cluster undergoes various lifecycle phases, which
 
 Hardware Validation is initiated during the cluster deployment process, assessing the state of hardware components for the machines provided through the Cluster's rack definition. Based on the results of these checks and any user skipped machines, a determination is done on whether sufficient nodes passed and/or are available to meet the thresholds necessary for deployment to continue.
 
+> **Note:**  
+> Hardware validation thresholds are enforced for various node types to ensure reliable cluster operation:
+> Management nodes are divided into two roles: Kubernetes Control Plane (KCP) nodes and Nexus Management Plane Nodes (NMP) nodes.
+> - **KCP nodes:** Must achieve a 100% hardware validation success rate since they make up the control plane.
+> - **NMP nodes:** These are grouped into two management groups, with each group required to meet a 50% hardware validation success rate.
+> - **Compute nodes:** Must meet the thresholds specified by the deployment input.
+
 Hardware validation results for a given server are written into the Log Analytics Workspace(LAW), which is provided as part of the cluster creation. The results include the following categories:
 - system_info
 - drive_info
@@ -31,11 +38,11 @@ This article provides instructions on how to check hardware results information
 
 ### Bootstrap phase:
 
-Once the Hardware Validation is successful, bootstrap image is generated for cluster deploy action on the cluster manager. This image iso URL is used to bootstrap the ephemeral node, which would deploy the target cluster components, which are provisioning the kubernetes control plane (KCP), Nexus Management plane (NMP), and storage appliance. These various states are reflected in the cluster status, which these stages are executed as part of the ephemeral bootstrap workflow.
+Once the Hardware Validation is successful and the thresholds necessary for deployment to continue are met, bootstrap image is generated for cluster deploy action on the cluster manager. This image iso URL is used to bootstrap the ephemeral node, which would deploy the target cluster components, which are provisioning the kubernetes control plane (KCP), Nexus Management plane (NMP), and storage appliance. These various states are reflected in the cluster status, which these stages are executed as part of the ephemeral bootstrap workflow.
 
 The ephemeral bootstrap node sequentially provisions each KCP node, and if a KCP node fails to provision, the cluster deployment action fails, marking the cluster status as failed. The Bootstrap operator manages the provisioning process for bare-metal nodes using the PXE boot approach.
 
-After successful provisioning of KCP nodes, the deployment action proceeds to provision NMP nodes in parallel. If an NMP node fails to provision, the cluster deployment action fails, resulting in the cluster status being marked as failed.
+Once KCP nodes are successfully provisioned, the deployment action proceeds to provision NMP nodes in parallel. Each management group must achieve at least a 50% provisioning success rate. If this requirement is not met, the cluster deployment action fails, resulting in the cluster status being marked as failed.
 
 Upon successful provisioning of NMP nodes, up to two storage appliances are created before the deployment action proceeds with provisioning the compute nodes. Compute nodes are provisioned in parallel, and once the defined compute node threshold is met, the cluster status transitions from Deploying to Running. However, the remaining nodes continue undergoing the provisioning process until they too are successfully provisioned.
 
@@ -44,4 +51,4 @@ Upon successful provisioning of NMP nodes, up to two storage appliances are crea
 
 - **List cluster**: List cluster information in the provided resource group or subscription.
 - **Show cluster**: Get properties of the provided cluster.
-- **Update cluster**: Update properties or tags of the provided cluster.
+- **Update cluster**: Update properties or tags of the provided cluster.

articles/virtual-network/ip-services/public-ip-upgrade-vm.md

@@ -108,6 +108,11 @@ There is no way to evaluate upgrading a Public IP without completing the action.
 
 Yes, the process of upgrading a Zonal Basic SKU Public IP to a Zonal Standard SKU Public IP is identical and works in the script.
 
+### If I specify a NIC associated with a public IP targeted for migration in the Application Gateway backend pool, will this script remove it from the pool?
+
+Yes, it will be removed. After running the script, you will need to manually reassign the NIC to the Application Gateway backend pool.
+Alternatively, you can avoid this issue by explicitly specifying the private IP address in the backend pool configuration before migration.
+
 ## Use Resource Graph to list VMs with Public IPs requiring upgrade
 
 ### Query to list virtual machines with Basic SKU public IP addresses