Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into cdnfreshness3

Author: duongau

articles/active-directory/governance/lifecycle-workflow-history.md

@@ -21,13 +21,13 @@ Workflows created using Lifecycle Workflows allow for the automation of lifecycl
 
 ## Lifecycle Workflow History Summaries
 
-Lifecycle Workflows introduce a history feature based on summaries and details. These history summaries allow you to quickly get information about for who a workflow ran, and whether or not this run was successful or not. This is valuable because the large set of information given by audit logs might become too numerous to be efficiently used. To make a large set of information processed easier to read, Lifecycle Workflows provide summaries for quick use. You can view these history summaries in three ways:
+Lifecycle Workflows introduce a history feature based on summaries and details. These history summaries allow you to quickly get information about for who a workflow ran, and whether or not this run was successful. This is valuable because the large set of information given by audit logs might become too numerous to be efficiently used. To make a large set of information processed easier to read, Lifecycle Workflows provide summaries for quick use. You can view these history summaries in three ways:
 
-- **Users summary**: Shows a summary of users processed by a workflow, and which tasks failed, successfully, and totally ran for each specific user. 
+- **Users summary**: Shows a summary of users processed by a workflow. Successfully, failed, and total ran information for each specific user is shown.
 - **Runs summary**: Shows a summary of workflow runs in terms of the workflow. Successful, failed, and total task information when workflow runs are noted.
 - **Tasks summary**: Shows a summary of tasks processed by a workflow, and which tasks failed, successfully, and totally ran in the workflow.
 
-Summaries allow you to quickly gain details about how a workflow ran for itself, or users, without going into further details in logs.  For a step by step guide on getting this information, see [Check the status of a workflow (Preview)](check-status-workflow.md)
+Summaries allow you to quickly gain details about how a workflow ran for itself, or users, without going into further details in logs.  For a step by step guide on getting this information, see [Check the status of a workflow (Preview)](check-status-workflow.md).
 
 ## Users Summary information
 
@@ -113,7 +113,7 @@ Task detailed history information allows you to filter for specific information
 - **Completed date**: You can filter a specific range from as short as 24 hours up to 30 days of when the workflow ran.
 - **Tasks**: You can filter based on specific task names.
 
-Separating processing of the workflow from the tasks is important because, in a workflow, processing a user certain tasks could be successful, while others could fail. Whether or not a task runs after a failed task in a workflow depends on parameters such as enabling continue On Error, and their placement within the workflow. For more information, see [Common task parameters](lifecycle-workflow-tasks.md#common-task-parameters-preview).
+Separating processing of the workflow from the tasks is important because, in a workflow, processing a user certain tasks could be successful, while others could fail. Whether or not a task runs after a failed task in a workflow depends on parameters such as enabling continue On Error, and their placement within the workflow. For more information, see [Common task parameters (preview)](lifecycle-workflow-tasks.md#common-task-parameters-preview).
 
 ## Next steps
 
@@ -123,4 +123,3 @@ Separating processing of the workflow from the tasks is important because, in a
 - [taskProcessingResult resource type](/graph/api/resources/identitygovernance-taskprocessingresult?view=graph-rest-beta&preserve-view=true)
 - [Understanding Lifecycle Workflows](understanding-lifecycle-workflows.md)
 - [Lifecycle Workflow templates](lifecycle-workflow-templates.md)
-

articles/aks/command-invoke.md

@@ -7,7 +7,7 @@ ms.date: 1/14/2022
 
 # Use `command invoke` to access a private Azure Kubernetes Service (AKS) cluster
 
-Accessing a private AKS cluster requires that you connect to that cluster either from the cluster virtual network, from a peered network, or via a configured private endpoint. These approaches require configuring a VPN, Express Route, deploying a *jumpbox* within the cluster virtual network, or creating a private endpoint inside of another virtual network. Alternatively, you can use `command invoke` to access private clusters without having to configure a VPN or Express Route. Using `command invoke` allows you to remotely invoke commands like `kubectl` and `helm` on your private cluster through the Azure API without directly connecting to the cluster. Permissions for using `command invoke` are controlled through the `Microsoft.ContainerService/managedClusters/runcommand/action` and `Microsoft.ContainerService/managedclusters/commandResults/read` roles.
+Accessing a private AKS cluster requires that you connect to that cluster either from the cluster virtual network, from a peered network, or via a configured private endpoint. These approaches require configuring a VPN, Express Route, deploying a *jumpbox* within the cluster virtual network, or creating a private endpoint inside of another virtual network. Alternatively, you can use `command invoke` to access private clusters without having to configure a VPN or Express Route. Using `command invoke` allows you to remotely invoke commands like `kubectl` and `helm` on your private cluster through the Azure API without directly connecting to the cluster. Permissions for using `command invoke` are controlled through the `Microsoft.ContainerService/managedClusters/runcommand/action` and `Microsoft.ContainerService/managedclusters/commandResults/read` actions.
 
 ## Prerequisites
 

articles/aks/concepts-security.md

@@ -42,7 +42,7 @@ You can control access to the API server using Kubernetes role-based access cont
 ## Node security
 
 AKS nodes are Azure virtual machines (VMs) that you manage and maintain.
-* Linux nodes run optimized versions of Ubuntu or CBL-Mariner.
+* Linux nodes run optimized versions of Ubuntu or Mariner.
 * Windows Server nodes run an optimized Windows Server 2019 release using the `containerd` or Docker container runtime.
 
 When an AKS cluster is created or scaled up, the nodes are automatically deployed with the latest OS security updates and configurations.

articles/aks/howto-deploy-java-liberty-app.md

@@ -30,7 +30,7 @@ This article uses the Azure Marketplace offer for Open/WebSphere Liberty to acce
 
 * This article requires at least version 2.31.0 of Azure CLI. If using Azure Cloud Shell, the latest version is already installed.
 * If running the commands in this guide locally (instead of Azure Cloud Shell):
-  * Prepare a local machine with Unix-like operating system installed (for example, Ubuntu, CBL-Mariner, macOS, Windows Subsystem for Linux).
+  * Prepare a local machine with Unix-like operating system installed (for example, Ubuntu, Mariner, macOS, Windows Subsystem for Linux).
   * Install a Java SE implementation (for example, [Eclipse Open J9](https://www.eclipse.org/openj9/)).
   * Install [Maven](https://maven.apache.org/download.cgi) 3.5.0 or higher.
   * Install [Docker](https://docs.docker.com/get-docker/) for your OS.

articles/aks/node-updates-kured.md

@@ -26,7 +26,7 @@ You need the Azure CLI version 2.0.59 or later installed and configured. Run `az
 
 ## Understand the AKS node update experience
 
-In an AKS cluster, your Kubernetes nodes run as Azure virtual machines (VMs). These Linux-based VMs use an Ubuntu or CBL-Mariner image, with the OS configured to automatically check for updates every day. If security or kernel updates are available, they are automatically downloaded and installed.
+In an AKS cluster, your Kubernetes nodes run as Azure virtual machines (VMs). These Linux-based VMs use an Ubuntu or Mariner image, with the OS configured to automatically check for updates every day. If security or kernel updates are available, they are automatically downloaded and installed.
 
 ![AKS node update and reboot process with kured](media/node-updates-kured/node-reboot-process.png)
 

articles/aks/workload-identity-migrate-from-pod-identity.md

@@ -120,7 +120,7 @@ If your application is using managed identity and still relies on IMDS to get an
 To update or deploy the workload, add these pod annotations only if you want to use the migration sidecar. You inject the following [annotation][pod-annotations] values to use the sidecar in your pod specification:
 
 * `azure.workload.identity/inject-proxy-sidecar` - value is `true` or `false`
-* `azure.workload.identity/proxy-sidecar-port` - value is the desired port for the proxy sidecar. The default value is `8080`.
+* `azure.workload.identity/proxy-sidecar-port` - value is the desired port for the proxy sidecar. The default value is `8000`.
 
 When a pod with the above annotations is created, the Azure Workload Identity mutating webhook automatically injects the init-container and proxy sidecar to the pod spec.
 
@@ -148,7 +148,7 @@ spec:
       runAsUser: 0
     env:
     - name: PROXY_PORT
-      value: "8080"
+      value: "8000"
   containers:
   - name: nginx
     image: nginx:alpine
@@ -157,7 +157,7 @@ spec:
   - name: proxy
     image: mcr.microsoft.com/oss/azure/workload-identity/proxy:v0.13.0
     ports:
-    - containerPort: 8080
+    - containerPort: 8000
 ```
 
 This configuration applies to any configuration where a pod is being created. After updating or deploying your application, you can verify the pod is in a running state using the [kubectl describe pod][kubectl-describe] command. Replace the value `podName` with the image name of your deployed pod.
@@ -210,4 +210,4 @@ This article showed you how to set up your pod to authenticate using a workload
 
 <!-- EXTERNAL LINKS -->
 [kubectl-describe]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#describe
-[kubelet-logs]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs
+[kubelet-logs]: https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#logs

articles/azure-functions/functions-bindings-azure-sql-output.md

@@ -845,7 +845,7 @@ def main(req: func.HttpRequest, todoItems: func.Out[func.SqlRow]) -> func.HttpRe
 
     try:
         req_body = req.get_json()
-        rows = list(map(lambda r: json.loads(r.to_json()), req_body))
+        rows = func.SqlRowList(map(lambda r: func.SqlRow.from_dict(r), req_body))
     except ValueError:
         pass
 
@@ -926,7 +926,7 @@ def main(req: func.HttpRequest, todoItems: func.Out[func.SqlRow], requestLog: fu
 
     try:
         req_body = req.get_json()
-        rows = list(map(lambda r: json.loads(r.to_json()), req_body))
+        rows = func.SqlRowList(map(lambda r: func.SqlRow.from_dict(r), req_body))
     except ValueError:
         pass
 

articles/azure-monitor/app/app-map.md

@@ -245,8 +245,8 @@ For the [official definitions](https://github.com/Microsoft/ApplicationInsights-
 ```
 
 Alternatively, *cloud role instance* can be helpful for scenarios where a cloud role name tells you the problem is somewhere in your web front end. But you might be running multiple load-balanced servers across your web front end. Being able to drill in a layer deeper via Kusto queries and knowing if the issue is affecting all web front-end servers or instances or just one can be important.
-intelligent view
-A scenario when you might want to override the value for cloud role instance could be if your app is running in a containerized environment. In this case, just knowing the individual server might not be enough information to locate a specific issue.
+
+Intelligent view A scenario when you might want to override the value for cloud role instance could be if your app is running in a containerized environment. In this case, just knowing the individual server might not be enough information to locate a specific issue.
 
 For more information about how to override the cloud role name property with telemetry initializers, see [Add properties: ITelemetryInitializer](api-filtering-sampling.md#addmodify-properties-itelemetryinitializer).
 

articles/azure-monitor/app/asp-net-dependencies.md

@@ -220,6 +220,10 @@ dependencies
 
 In the Log Analytics query view, `timestamp` represents the moment the TrackDependency() call was initiated, which occurs immediately after the dependency call response is received. To calculate the time when the dependency call began, you would take `timestamp` and subtract the recorded `duration` of the dependency call.
 
+### Does dependency tracking in Application Insights include logging response bodies?
+
+Dependency tracking in Application Insights does not include logging response bodies as it would generate too much telemetry for most applications.
+
 ## Open-source SDK
 
 Like every Application Insights SDK, the dependency collection module is also open source. Read and contribute to the code or report issues at [the official GitHub repo](https://github.com/Microsoft/ApplicationInsights-dotnet).
@@ -273,4 +277,4 @@ A list of the latest [currently supported modules](https://github.com/microsoft/
 * Set up custom dependency tracking for [OpenCensus Python](./opencensus-python-dependency.md).
 * [Write custom dependency telemetry](./api-custom-events-metrics.md#trackdependency)
 * See [data model](./data-model.md) for Application Insights types and data model.
-* Check out [platforms](./app-insights-overview.md#supported-languages) supported by Application Insights.
+* Check out [platforms](./app-insights-overview.md#supported-languages) supported by Application Insights.

articles/azure-monitor/app/correlation.md

@@ -159,7 +159,21 @@ For a reference, you can find the OpenCensus data model on [this GitHub page](ht
 
 OpenCensus Python correlates W3C Trace-Context headers from incoming requests to the spans that are generated from the requests themselves. OpenCensus will correlate automatically with integrations for these popular web application frameworks: Flask, Django, and Pyramid. You just need to populate the W3C Trace-Context headers with the [correct format](https://www.w3.org/TR/trace-context/#trace-context-http-headers-format) and send them with the request.
 
-**Sample Flask application**
+Explore this sample Flask application. Install Flask, OpenCensus, and the extensions for Flask and Azure.
+
+```shell
+
+pip install flask opencensus opencensus-ext-flask opencensus-ext-azure
+
+```
+
+You will need to add your Application Insights connection string to the environment variable.
+
+```shell
+APPLICATIONINSIGHTS_CONNECTION_STRING=<appinsights-connection-string>
+```
+
+**Sample Flask Application**
 
 ```python
 from flask import Flask
@@ -170,7 +184,9 @@ from opencensus.trace.samplers import ProbabilitySampler
 app = Flask(__name__)
 middleware = FlaskMiddleware(
     app,
-    exporter=AzureExporter(),
+    exporter=AzureExporter(
+        connection_string='<appinsights-connection-string>', # or set environment variable APPLICATION_INSIGHTS_CONNECTION_STRING
+    ), 
     sampler=ProbabilitySampler(rate=1.0),
 )
 
@@ -248,49 +264,59 @@ You can export the log data by using `AzureLogHandler`. For more information, se
 
 We can also pass trace information from one component to another for proper correlation. For example, consider a scenario where there are two components, `module1` and `module2`. Module1 calls functions in Module2. To get logs from both `module1` and `module2` in a single trace, we can use the following approach:
 
+
 ```python
 # module1.py
 import logging
 
 from opencensus.trace import config_integration
 from opencensus.trace.samplers import AlwaysOnSampler
 from opencensus.trace.tracer import Tracer
-from module2 import function_1
+from module_2 import function_1
 
-config_integration.trace_integrations(['logging'])
-logging.basicConfig(format='%(asctime)s traceId=%(traceId)s spanId=%(spanId)s %(message)s')
+config_integration.trace_integrations(["logging"])
+logging.basicConfig(
+    format="%(asctime)s traceId=%(traceId)s spanId=%(spanId)s %(message)s"
+)
 tracer = Tracer(sampler=AlwaysOnSampler())
 
 logger = logging.getLogger(__name__)
-logger.warning('Before the span')
-with tracer.span(name='hello'):
-   logger.warning('In the span')
-   function_1(tracer)
-logger.warning('After the span')
+logger.warning("Before the span")
 
-# module2.py
+with tracer.span(name="hello"):
+    logger.warning("In the span")
+    function_1(logger, tracer)
+logger.warning("After the span")
+```
 
+```python
+# module_2.py
 import logging
 
 from opencensus.trace import config_integration
 from opencensus.trace.samplers import AlwaysOnSampler
 from opencensus.trace.tracer import Tracer
 
-config_integration.trace_integrations(['logging'])
-logging.basicConfig(format='%(asctime)s traceId=%(traceId)s spanId=%(spanId)s %(message)s')
+config_integration.trace_integrations(["logging"])
+logging.basicConfig(
+    format="%(asctime)s traceId=%(traceId)s spanId=%(spanId)s %(message)s"
+)
+logger = logging.getLogger(__name__)
 tracer = Tracer(sampler=AlwaysOnSampler())
 
-def function_1(parent_tracer=None):
+
+def function_1(logger=logger, parent_tracer=None):
     if parent_tracer is not None:
         tracer = Tracer(
-                    span_context=parent_tracer.span_context,
-                    sampler=AlwaysOnSampler(),
-                )
+            span_context=parent_tracer.span_context,
+            sampler=AlwaysOnSampler(),
+        )
     else:
         tracer = Tracer(sampler=AlwaysOnSampler())
 
     with tracer.span("function_1"):
         logger.info("In function_1")
+
 ```
 
 ## Telemetry correlation in .NET