Merge pull request #258621 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/azure-boost/overview.md

@@ -57,7 +57,7 @@ Azure Boost delivers industry leading throughput performance at up to 12.5-GBps
 
 :::image type="content" source="./media/boost-storage-nvme-vs-scsi.png" alt-text="Diagram showing the difference between managed SCSI storage and Azure Boost's managed NVMe storage.":::
 
-By fully applying Azure Boost architecture, we deliver remote, local, and cached disk performance improvements at up to 17-GBps throughput and 3.8M IOPS. Azure Boost SSDd are designed to provide high performance optimized encryption at rest, and minimal jitter to NVMe local disks for Azure VMs with local disks.
+By fully applying Azure Boost architecture, we deliver remote, local, and cached disk performance improvements at up to 17-GBps throughput and 3.8M IOPS. Azure Boost SSDs are designed to provide high performance optimized encryption at rest, and minimal jitter to NVMe local disks for Azure VMs with local disks.
 
 :::image type="content" source="./media/boost-storage-ssd-comparison.png" alt-text="Diagram showing the difference between local SCSI SSDs and Azure Boost's local NVMe SSDs.":::
 

articles/azure-functions/durable/durable-functions-entities.md

@@ -261,6 +261,28 @@ module.exports = df.entity(function(context) {
 ::: zone pivot="python"
 The following code is the `Counter` entity implemented as a durable function written in Python.
 
+# [v2](#tab/python-v2)
+
+```Python
+import azure.functions as func
+import azure.durable_functions as df
+
+# Entity function called counter
+@myApp.entity_trigger(context_name="context")
+def Counter(context):
+    current_value = context.get_state(lambda: 0)
+    operation = context.operation_name
+    if operation == "add":
+        amount = context.get_input()
+        current_value += amount
+    elif operation == "reset":
+        current_value = 0
+    elif operation == "get":
+        context.set_result(current_value)
+    context.set_state(current_value)
+```
+
+# [v1](#tab/python-v1)
 **Counter/function.json**
 ```json
 {
@@ -362,7 +384,25 @@ module.exports = async function (context) {
 };
 ```
 ::: zone-end  
-::: zone pivot="python"  
+::: zone pivot="python"
+
+# [v2](#tab/python-v2)
+```Python
+import azure.functions as func
+import azure.durable_functions as df
+
+# An HTTP-Triggered Function with a Durable Functions Client to set a value on a durable entity
+@myApp.route(route="entitysetvalue")
+@myApp.durable_client_input(client_name="client")
+async def http_set(req: func.HttpRequest, client):
+    logging.info('Python HTTP trigger function processing a request.')
+    entityId = df.EntityId("Counter", "myCounter")
+    await client.signal_entity(entityId, "add", 1)
+    return func.HttpResponse("Done", status_code=200)
+```
+
+# [v1](#tab/python-v1)
+
 ```Python
 from azure.durable_functions import DurableOrchestrationClient
 import azure.functions as func
@@ -431,7 +471,25 @@ module.exports = async function (context) {
 };
 ```
 ::: zone-end  
-::: zone pivot="python"  
+::: zone pivot="python"
+
+# [v2](#tab/python-v2)
+
+```python
+# An HTTP-Triggered Function with a Durable Functions Client to retrieve the state of a durable entity
+@myApp.route(route="entityreadvalue")
+@myApp.durable_client_input(client_name="client")
+async def http_read(req: func.HttpRequest, client):
+    entityId = df.EntityId("Counter", "myCounter")
+    entity_state_result = await client.read_entity_state(entityId)
+    entity_state = "No state found"
+    if entity_state_result.entity_exists:
+      entity_state = str(entity_state_result.entity_state)
+    return func.HttpResponse(entity_state)
+```
+
+# [v1](#tab/python-v1)
+
 ```python
 from azure.durable_functions import DurableOrchestrationClient
 import azure.functions as func
@@ -508,7 +566,21 @@ module.exports = df.orchestrator(function*(context){
 > [!NOTE]
 > JavaScript does not currently support signaling an entity from an orchestrator. Use `callEntity` instead.
 ::: zone-end  
-::: zone pivot="python"  
+::: zone pivot="python"
+
+# [v2](#tab/python-v2)
+
+```python
+@myApp.orchestration_trigger(context_name="context")
+def orchestrator(context: df.DurableOrchestrationContext):
+    entityId = df.EntityId("Counter", "myCounter")
+    context.signal_entity(entityId, "add", 3)
+    logging.info("signaled entity")
+    state = yield context.call_entity(entityId, "get")
+    return state
+```
+
+# [v1](#tab/python-v1)
 ```Python
 import azure.functions as func
 import azure.durable_functions as df

articles/azure-monitor/containers/container-insights-agent-config.md

@@ -2,7 +2,7 @@
 title: Configure Container insights agent data collection | Microsoft Docs
 description: This article describes how you can configure the Container insights agent to control stdout/stderr and environment variables log collection.
 ms.topic: conceptual
-ms.date: 08/25/2022
+ms.date: 11/14/2023
 ms.reviewer: aul
 ---
 
@@ -23,6 +23,9 @@ A template ConfigMap file is provided so that you can easily edit it with your c
 
 The following table describes the settings you can configure to control data collection.
 
+>[!NOTE]
+>For clusters enabling container insights using Azure CLI version 2.54.0 or greater, the default setting for `[log_collection_settings.schema]` will be set to "v2"
+
 | Key | Data type | Value | Description |
 |--|--|--|--|
 | `schema-version` | String (case sensitive) | v1 | This schema version is used by the agent<br> when parsing this ConfigMap.<br> Currently supported schema-version is v1.<br> Modifying this value isn't supported and will be<br> rejected when the ConfigMap is evaluated. |
@@ -34,6 +37,7 @@ The following table describes the settings you can configure to control data col
 | `[log_collection_settings.env_var] enabled =` | Boolean | True or false | This setting controls environment variable collection<br> across all pods/nodes in the cluster<br> and defaults to `enabled = true` when not specified<br> in the ConfigMap.<br> If collection of environment variables is globally enabled, you can disable it for a specific container<br> by setting the environment variable<br> `AZMON_COLLECT_ENV` to `False` either with a Dockerfile setting or in the [configuration file for the Pod](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/) under the `env:` section.<br> If collection of environment variables is globally disabled, you can't enable collection for a specific container. The only override that can be applied at the container level is to disable collection when it's already enabled globally. |
 | `[log_collection_settings.enrich_container_logs] enabled =` | Boolean | True or false | This setting controls container log enrichment to populate the `Name` and `Image` property values<br> for every log record written to the **ContainerLog** table for all container logs in the cluster.<br> It defaults to `enabled = false` when not specified in the ConfigMap. |
 | `[log_collection_settings.collect_all_kube_events] enabled =` | Boolean | True or false | This setting allows the collection of Kube events of all types.<br> By default, the Kube events with type **Normal** aren't collected. When this setting is set to `true`, the **Normal** events are no longer filtered, and all events are collected.<br> It defaults to `enabled = false` when not specified in the ConfigMap. |
+| `[log_collection_settings.schema] enabled =` | String (case sensitive) | v2 or v1 [(retired)](./container-insights-v2-migration.md) | This setting sets the log ingestion format to ContainerLogV2 |
 | `[log_collection_settings.enable_multiline_logs] enabled =` | Boolean | True or False | This setting controls whether multiline container logs are enabled. They are disabled by default. See [Multi-line logging in Container Insights](./container-insights-logging-v2.md) to learn more. |
 
 ### Metric collection settings

articles/azure-monitor/containers/container-insights-enable-aks.md

@@ -2,7 +2,7 @@
 title: Enable Container insights for Azure Kubernetes Service (AKS) cluster
 description: Learn how to enable Container insights on an Azure Kubernetes Service (AKS) cluster.
 ms.topic: conceptual
-ms.date: 01/09/2023
+ms.date: 11/14/2023
 ms.custom: ignite-2022, devx-track-azurecli
 ms.reviewer: aul
 ---
@@ -33,7 +33,7 @@ Use any of the following methods to enable monitoring for an existing AKS cluste
 ## [CLI](#tab/azure-cli)
 
 > [!NOTE]
-> Managed identity authentication will be default in CLI version 2.49.0 or higher. If you need to use legacy/non-managed identity authentication, use CLI version < 2.49.0.
+> Managed identity authentication will be default in CLI version 2.49.0 or higher. If you need to use legacy/non-managed identity authentication, use CLI version < 2.49.0. For CLI version 2.54.0 or higher the logging schema will be configured to [ContainerLogV2](./container-insights-logging-v2.md) via the ConfigMap
 
 ### Use a default Log Analytics workspace
 

articles/azure-monitor/containers/container-insights-logging-v2.md

@@ -14,7 +14,7 @@ ms.reviewer: aul
 Azure Monitor Container insights offers a schema for container logs, called ContainerLogV2. As part of this schema, there are fields to make common queries to view Azure Kubernetes Service (AKS) and Azure Arc-enabled Kubernetes data. In addition, this schema is compatible with [Basic Logs](../logs/basic-logs-configure.md), which offers a low-cost alternative to standard analytics logs.
 
 >[!NOTE]
-> ContainerLogV2 will be default schema for customers who will be onboarding container insights with Managed Identity Auth using ARM, Bicep, Terraform, Policy and Portal onboarding. ContainerLogV2 can be explicitly enabled through CLI version 2.51.0 or higher using Data collection settings.
+> ContainerLogV2 will be the default schema via the ConfigMap for CLI version 2.54.0 and greater. ContainerLogV2 will be default ingestion format for customers who will be onboarding container insights with Managed Identity Auth using ARM, Bicep, Terraform, Policy and Portal onboarding. ContainerLogV2 can be explicitly enabled through CLI version 2.51.0 or higher using Data collection settings.
 
 The new fields are:
 * `ContainerName`
@@ -85,8 +85,8 @@ This applies to the scenario where you have already enabled container insights f
 ```
 
 ### Configure a new ConfigMap
-1. [Download the new ConfigMap](https://aka.ms/container-azm-ms-agentconfig). For the newly downloaded ConfigMap, the default value for `containerlog_schema_version` is `"v1"`.
-1. Update `containerlog_schema_version` to `"v2"`:
+1. [Download the new ConfigMap](https://aka.ms/container-azm-ms-agentconfig). For the newly downloaded ConfigMap, the default value for `containerlog_schema_version` is `"v2"`.
+1. Ensure that the  `containerlog_schema_version` to `"v2"` and the `[log_collection_settings.schema]` is also uncommented by removing the `#` preceding it:
 
     ```yaml
     [log_collection_settings.schema]

articles/batch/batch-task-output-files.md

@@ -41,7 +41,11 @@ CloudBlobContainer container = storageAccount.CreateCloudBlobClient().GetContain
 await container.CreateIfNotExists();
 ```
 
-## Get a shared access signature for the container
+## Specify output files for task output
+
+To specify output files for a task, create a collection of [OutputFile](/dotnet/api/microsoft.azure.batch.outputfile) objects and assign it to the [CloudTask.OutputFiles](/dotnet/api/microsoft.azure.batch.cloudtask.outputfiles) property when you create the task. You can use a Shared Access Signature (SAS) or managed identity to authenticate access to the container.
+
+### Using a Shared Access Signature
 
 After you create the container, get a shared access signature (SAS) with write access to the container. A SAS provides delegated access to the container. The SAS grants access with a specified set of permissions and over a specified time interval. The Batch service needs an SAS with write permissions to write task output to the container. For more information about SAS, see [Using shared access signatures \(SAS\) in Azure Storage](../storage/common/storage-sas-overview.md).
 
@@ -59,10 +63,6 @@ string containerSasToken = container.GetSharedAccessSignature(new SharedAccessBl
 string containerSasUrl = container.Uri.AbsoluteUri + containerSasToken;
 ```
 
-## Specify output files for task output
-
-To specify output files for a task, create a collection of [OutputFile](/dotnet/api/microsoft.azure.batch.outputfile) objects and assign it to the [CloudTask.OutputFiles](/dotnet/api/microsoft.azure.batch.cloudtask.outputfiles) property when you create the task.
-
 The following C# code example creates a task that writes random numbers to a file named `output.txt`. The example creates an output file for `output.txt` to be written to the container. The example also creates output files for any log files that match the file pattern `std*.txt` (_e.g._, `stdout.txt` and `stderr.txt`). The container URL requires the SAS that was created previously for the container. The Batch service uses the SAS to authenticate access to the container.
 
 ```csharp
@@ -92,7 +92,7 @@ new CloudTask(taskId, "cmd /v:ON /c \"echo off && set && (FOR /L %i IN (1,1,1000
 > [!NOTE]
 > If using this example with Linux, be sure to change the backslashes to forward slashes.
 
-## Specify output files using managed identity
+### Using Managed Identity
 
 Instead of generating and passing a SAS with write access to the container to Batch, a managed identity can be used to authenticate with Azure Storage. The identity must be [assigned to the Batch Pool](managed-identity-pools.md), and also have the `Storage Blob Data Contributor` role assignment for the container to be written to. The Batch service can then be told to use the managed identity instead of a SAS to authenticate access to the container.
 
@@ -165,6 +165,12 @@ https://myaccount.blob.core.windows.net/mycontainer/task2/output.txt
 
 For more information about virtual directories in Azure Storage, see [List the blobs in a container](../storage/blobs/storage-quickstart-blobs-dotnet.md#list-blobs-in-a-container).
 
+### Many Output Files
+
+When a task specifies numerous output files, you may encounter limits imposed by the Azure Batch API. It is advisable to keep your tasks small and keep the number of output files low.
+
+If you encounter limits, consider reducing the number of output files by employing [File Patterns](#specify-a-file-pattern-for-matching) or using file containers such as tar or zip to consolidate the output files. Alternatively, utilize mounting or other approaches to persist output data (see [Persist job and task output](batch-task-output.md)).
+
 ## Diagnose file upload errors
 
 If uploading output files to Azure Storage fails, then the task moves to the **Completed** state and the [Task​Execution​Information.​Failure​Information](/dotnet/api/microsoft.azure.batch.taskexecutioninformation.failureinformation) property is set. Examine the **FailureInformation** property to determine what error occurred. For example, here is an error that occurs on file upload if the container cannot be found:

articles/batch/managed-identity-pools.md

@@ -112,7 +112,7 @@ Azure Container Registry, support managed identities. For more information on us
 see the following links:
 
 - [Resource files](resource-files.md)
-- [Output files](batch-task-output-files.md#specify-output-files-using-managed-identity)
+- [Output files](batch-task-output-files.md#using-managed-identity)
 - [Azure Container Registry](batch-docker-container-workloads.md#managed-identity-support-for-acr)
 - [Azure Blob container file system](virtual-file-mount.md#azure-blob-container)
 

articles/container-apps/health-probes.md

@@ -167,8 +167,8 @@ If ingress is enabled, the following default probes are automatically added to t
 
 | Probe type | Default values |
 | -- | -- |
-| Startup | Protocol: TCP<br>Port: ingress target port<br>Timeout: 3 seconds<br>Period: 1 second<br>Initial delay: 1 second<br>Success threshold: 1 second<br>Failure threshold: 240 seconds |
-| Readiness | Protocol: TCP<br>Port: ingress target port<br>Timeout: 5 seconds<br>Period: 5 seconds<br>Initial delay: 3 seconds<br>Success threshold: 1 second<br>Failure threshold: 48 seconds |
+| Startup | Protocol: TCP<br>Port: ingress target port<br>Timeout: 3 seconds<br>Period: 1 second<br>Initial delay: 1 second<br>Success threshold: 1<br>Failure threshold: 240 |
+| Readiness | Protocol: TCP<br>Port: ingress target port<br>Timeout: 5 seconds<br>Period: 5 seconds<br>Initial delay: 3 seconds<br>Success threshold: 1<br>Failure threshold: 48 |
 | Liveness | Protocol: TCP<br>Port: ingress target port |
 
 If your app takes an extended amount of time to start (which is common in Java) you often need to customize the probes so your container doesn't crash.

articles/hdinsight-aks/trino/trino-jvm-configuration.md

@@ -41,7 +41,7 @@ The following example sets the initial and max heap size to 6 GB and 10 GB for b
                         "fileName": "jvm.config",
                         "values": {
                             "-Xms": "6G",
-                            "-Xmm": "10G"
+                            "-Xmx": "10G"
                         }
                     }
                 ]                

articles/networking/azure-for-network-engineers.md

@@ -64,15 +64,15 @@ When you have competing entries in a routing table, Azure selects the next hop b
 
 You can filter network traffic to and from resources in a virtual network using network security groups. You can also use network virtual appliances (NVA) such as Azure Firewall or firewalls from other vendors. You can control how Azure routes traffic from subnets. You can also limit who in your organization can work with resources in virtual networks.
 
-A network security group (NSG) contains a list of Access Control List (ACL) rules that allow or deny network traffic to subnets, NICs, or both. NSGs can be associated with either subnets or individual NICs connected to a subnet. When an NSG is associated with a subnet, the ACL rules apply to all the VMs in that subnet. In addition, traffic to an individual NIC can be restricted by associating an NSG directly to a NIC.
+A network security group (NSG) contains a list of Access Control List (ACL) rules that allow or deny network traffic to subnets, NICs, or both. NSGs can be associated with either subnets or individual NICs connected to a subnet. When an NSG is associated with a subnet, the ACL rules apply to all the VMs in that subnet. In addition, traffic to an individual NIC can be restricted by associating an NSG directly with a NIC.
 
 NSGs contain two sets of rules: inbound and outbound. The priority for a rule must be unique within each set. Each rule has properties of protocol, source and destination port ranges, address prefixes, direction of traffic, priority, and access type. All NSGs contain a set of default rules. The default rules cannot be deleted, but because they are assigned the lowest priority, they can be overridden by the rules that you create.
 
 ## Verification
 ### Routes in virtual network
-The combination of routes you create, Azure's default routes, and any routes propagated from your on-premises network through an Azure VPN gateway (if your virtual network is connected to your on-premises network) via the border gateway protocol (BGP), are the effective routes for all network interfaces in a subnet. You can see these effective routes by navigating to NIC either via Portal, PowerShell, or CLI.
+The combination of routes you create, Azure's default routes, and any routes propagated from your on-premises network through an Azure VPN gateway (if your virtual network is connected to your on-premises network) via the border gateway protocol (BGP), are the effective routes for all network interfaces in a subnet. You can see these effective routes by navigating to NIC either via Portal, PowerShell, or CLI. For more information on effective routes on a NIC, please see [Get-AzEffectiveRouteTable](/powershell/module/az.network/get-azeffectiveroutetable).
 ### Network Security Groups
-The effective security rules applied to a network interface are an aggregation of the rules that exist in the NSG associated to a network interface, and the subnet the network interface is in. You can view all the effective security rules from NSGs that are applied on your VM's network interfaces by navigating to the NIC via Portal, PowerShell, or CLI.
+The effective security rules applied to a network interface are an aggregation of the rules that exist in the NSG associated with a network interface, and the subnet the network interface is in. You can view all the effective security rules from NSGs that are applied to your VM's network interfaces by navigating to the NIC via Portal, PowerShell, or CLI.
 
 ## Next steps