Merge pull request #189565 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: huypub

articles/azure-monitor/containers/container-insights-optout-openshift-v4.md

@@ -15,7 +15,7 @@ After you enable monitoring of your Azure Red Hat OpenShift and Red Hat OpenShif
 1. To first identify the Container insights helm chart release installed on your cluster, run the following helm command.
 
     ```
-    helm list
+    helm list --all-namespaces
     ```
 
     The output will resemble the following:
@@ -45,4 +45,4 @@ The configuration change can take a few minutes to complete. Because Helm tracks
 
 ## Next steps
 
-If the Log Analytics workspace was created only to support monitoring the cluster and it's no longer needed, you have to manually delete it. If you are not familiar with how to delete a workspace, see [Delete an Azure Log Analytics workspace](../logs/delete-workspace.md).
+If the Log Analytics workspace was created only to support monitoring the cluster and it's no longer needed, you have to manually delete it. If you are not familiar with how to delete a workspace, see [Delete an Azure Log Analytics workspace](../logs/delete-workspace.md).

articles/service-bus-messaging/message-transfers-locks-settlement.md

@@ -119,7 +119,7 @@ The typical mechanism for identifying duplicate message deliveries is by checkin
 >   * OS update
 >   * Changing properties on the entity (Queue, Topic, Subscription) while holding the lock.
 >
-> When the lock is lost, Azure Service Bus will generate a LockLostException which will be surfaced on the client application code. In this case, the client's default retry logic should automatically kick in and retry the operation.
+> When the lock is lost, Azure Service Bus will generate a MessageLockLostException which will be surfaced on the client application code. In this case, the client's default retry logic should automatically kick in and retry the operation.
 
 ## Renew locks
 The default value for the lock duration is **30 seconds**. You can specify a different value for the lock duration at the queue or subscription level. The client owning the lock can renew the message lock by using methods on the receiver object. Instead, you can use the automatic lock-renewal feature where you can specify the time duration for which you want to keep getting the lock renewed. 

articles/service-fabric/service-fabric-cluster-resource-manager-metrics.md

@@ -114,7 +114,7 @@ serviceDescription.Metrics.Add(totalCountMetric);
 await fabricClient.ServiceManager.CreateServiceAsync(serviceDescription);
 ```
 
-Powershell:
+PowerShell:
 
 ```posh
 New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("ConnectionCount,High,20,5”,"PrimaryCount,Medium,1,0”,"ReplicaCount,Low,1,1”,"Count,Low,1,1”)
@@ -258,7 +258,7 @@ Let’s take our previous example and see what happens when we add some custom m
 
 Let’s presume that we initially created the stateful service with the following command:
 
-Powershell:
+PowerShell:
 
 ```posh
 New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName –Stateful -MinReplicaSetSize 3 -TargetReplicaSetSize 3 -PartitionSchemeSingleton –Metric @("MemoryInMb,High,21,11”,"PrimaryCount,Medium,1,0”,"ReplicaCount,Low,1,1”,"Count,Low,1,1”)

articles/service-fabric/service-fabric-concepts-scalability.md

@@ -33,7 +33,7 @@ updateDescription.InstanceCount = 50;
 await fabricClient.ServiceManager.UpdateServiceAsync(new Uri("fabric:/app/service"), updateDescription);
 ```
 
-Powershell:
+PowerShell:
 
 ```posh
 Update-ServiceFabricService -Stateless -ServiceName $serviceName -InstanceCount 50
@@ -50,7 +50,7 @@ serviceDescription.InstanceCount = -1;
 await fc.ServiceManager.CreateServiceAsync(serviceDescription);
 ```
 
-Powershell:
+PowerShell:
 
 ```posh
 New-ServiceFabricService -ApplicationName $applicationName -ServiceName $serviceName -ServiceTypeName $serviceTypeName -Stateless -PartitionSchemeSingleton -InstanceCount "-1"

articles/service-fabric/service-fabric-containers-volume-logging-drivers.md

@@ -22,7 +22,7 @@ The Azure Files volume driver is a [Docker volume plugin](https://docs.docker.co
 
 * Follow the instructions in the [Azure Files documentation](../storage/files/storage-how-to-create-file-share.md) to create a file share for the Service Fabric container application to use as volume.
 
-* You will need [Powershell with the Service Fabric module](./service-fabric-get-started.md) or [SFCTL](./service-fabric-cli.md) installed.
+* You will need [PowerShell with the Service Fabric module](./service-fabric-get-started.md) or [SFCTL](./service-fabric-cli.md) installed.
 
 * If you are using Hyper-V containers, the following snippets need to be added in the ClusterManifest (local cluster) or fabricSettings section in your Azure Resource Manager template (Azure cluster) or ClusterConfig.json (standalone cluster).
 
@@ -52,7 +52,7 @@ In the fabricSettings section in your Azure Resource Manager template (for Azure
 
 ## Deploy a sample application using Service Fabric Azure Files volume driver
 
-### Using Azure Resource Manager via the provided Powershell script (recommended)
+### Using Azure Resource Manager via the provided PowerShell script (recommended)
 
 If your cluster is based in Azure, we recommend deploying applications to it using the Azure Resource Manager application resource model for ease of use and to help move towards the model of maintaining infrastructure as code. This approach eliminates the need to keep track of the app version for the Azure Files volume driver. It also enables you to maintain separate Azure Resource Manager templates for each supported OS. The script assumes you are deploying the latest version of the Azure Files application and takes parameters for OS type, cluster subscription ID, and resource group. You can download the script from the [Service Fabric download site](https://sfazfilevd.blob.core.windows.net/sfazfilevd/DeployAzureFilesVolumeDriver.zip). Note that this automatically sets the ListenPort, which is the port on which the Azure Files volume plugin listens for requests from the Docker daemon, to 19100. You can change it by adding parameter named "listenPort". Ensure that the port does not conflict with any other port that the cluster or your applications uses.
 

articles/service-fabric/service-fabric-controlled-chaos.md

@@ -12,13 +12,13 @@ The [Fault Injection and Cluster Analysis Service](./service-fabric-testability-
 
 Chaos simulates periodic, interleaved faults (both graceful and ungraceful) throughout the cluster over extended periods of time. A graceful fault consists of a set of Service Fabric API calls, for example, restart replica fault is a graceful fault because this is a close followed by an open on a replica. Remove replica, move primary replica, move secondary replica, and move instance are the other graceful faults exercised by Chaos. Ungraceful faults are process exits, like restart node and restart code package.
 
-Once you have configured Chaos with the rate and the kind of faults, you can start Chaos through C#, Powershell, or REST API to start generating faults in the cluster and in your services. You can configure Chaos to run for a specified time period (for example, for one hour), after which Chaos stops automatically, or you can call StopChaos API (C#, Powershell, or REST) to stop it at any time.
+Once you have configured Chaos with the rate and the kind of faults, you can start Chaos through C#, PowerShell, or REST API to start generating faults in the cluster and in your services. You can configure Chaos to run for a specified time period (for example, for one hour), after which Chaos stops automatically, or you can call StopChaos API (C#, PowerShell, or REST) to stop it at any time.
 
 > [!NOTE]
 > In its current form, Chaos induces only safe faults, which implies that in the absence of external faults a quorum loss, or data loss never occurs.
 >
 
-While Chaos is running, it produces different events that capture the state of the run at the moment. For example, an ExecutingFaultsEvent contains all the faults that Chaos has decided to execute in that iteration. A ValidationFailedEvent contains the details of a validation failure (health or stability issues) that was found during the validation of the cluster. You can invoke the GetChaosReport API (C#, Powershell, or REST) to get the report of Chaos runs. These events get persisted in a [reliable dictionary](./service-fabric-reliable-services-reliable-collections.md), which has a truncation policy dictated by two configurations: **MaxStoredChaosEventCount** (default value is 25000) and **StoredActionCleanupIntervalInSeconds** (default value is 3600). Every *StoredActionCleanupIntervalInSeconds* Chaos checks and all but the most recent *MaxStoredChaosEventCount* events, are purged from the reliable dictionary.
+While Chaos is running, it produces different events that capture the state of the run at the moment. For example, an ExecutingFaultsEvent contains all the faults that Chaos has decided to execute in that iteration. A ValidationFailedEvent contains the details of a validation failure (health or stability issues) that was found during the validation of the cluster. You can invoke the GetChaosReport API (C#, PowerShell, or REST) to get the report of Chaos runs. These events get persisted in a [reliable dictionary](./service-fabric-reliable-services-reliable-collections.md), which has a truncation policy dictated by two configurations: **MaxStoredChaosEventCount** (default value is 25000) and **StoredActionCleanupIntervalInSeconds** (default value is 3600). Every *StoredActionCleanupIntervalInSeconds* Chaos checks and all but the most recent *MaxStoredChaosEventCount* events, are purged from the reliable dictionary.
 
 ## Faults induced in Chaos
 Chaos generates faults across the entire Service Fabric cluster and compresses faults that are seen in months or years into a few hours. The combination of interleaved faults with the high fault rate finds corner cases that may otherwise be missed. This exercise of Chaos leads to a significant improvement in the code quality of the service.

articles/service-fabric/service-fabric-deploy-remove-applications.md

@@ -1,6 +1,6 @@
 ---
 title: Azure Service Fabric deployment with PowerShell
-description: Learn about removing and deploying applications in Azure Service Fabric and how to perform these actions in Powershell.
+description: Learn about removing and deploying applications in Azure Service Fabric and how to perform these actions in PowerShell.
 
 ms.topic: conceptual
 ms.date: 01/19/2018

articles/service-fabric/service-fabric-dnsservice.md

@@ -138,8 +138,8 @@ The following example sets the DNS name for a stateful service to `statefulsvc.a
     </Service>
 ```
 
-### Setting the DNS name for a service using Powershell
-You can set the DNS name for a service when creating it using the `New-ServiceFabricService` Powershell command. The following example creates a new stateless service with the DNS name `service1.application1`
+### Setting the DNS name for a service using PowerShell
+You can set the DNS name for a service when creating it using the `New-ServiceFabricService` PowerShell command. The following example creates a new stateless service with the DNS name `service1.application1`
 
 ```powershell
     New-ServiceFabricService `

articles/service-fabric/service-fabric-linux-windows-differences.md

@@ -13,10 +13,10 @@ There are some features that are supported on Windows, but not yet on Linux. Eve
 * Console redirection (not supported in Linux or Windows production clusters)
 * The Fault Analysis Service (FAS) on Linux
 * DNS service for Service Fabric services (DNS service is supported for containers on Linux)
-* CLI command equivalents of certain Powershell commands (list below, most of which apply only to standalone clusters)
+* CLI command equivalents of certain PowerShell commands (list below, most of which apply only to standalone clusters)
 * [Differences in log implementation that may affect scalability](service-fabric-concepts-scalability.md#choosing-a-platform)
 
-## Powershell cmdlets that do not work against a Linux Service Fabric cluster
+## PowerShell cmdlets that do not work against a Linux Service Fabric cluster
 
 * Invoke-ServiceFabricChaosTestScenario
 * Invoke-ServiceFabricFailoverTestScenario

articles/service-fabric/service-fabric-package-apps.md

@@ -131,7 +131,7 @@ For a compressed application package, [uploading the application package](servic
 The deployment mechanism is same for compressed and uncompressed packages. If the package is compressed, it is stored as such in the cluster image store and it's uncompressed on the node before the application is run.
 The compression replaces the valid Service Fabric package with the compressed version. The folder must allow write permissions. Running compression on an already compressed package yields no changes.
 
-You can compress a package by running the Powershell command [Copy-ServiceFabricApplicationPackage](/powershell/module/servicefabric/copy-servicefabricapplicationpackage)
+You can compress a package by running the PowerShell command [Copy-ServiceFabricApplicationPackage](/powershell/module/servicefabric/copy-servicefabricapplicationpackage)
 with `CompressPackage` switch. You can uncompress the package with the same command, using `UncompressPackage` switch.
 
 The following command compresses the package without copying it to the image store. You can copy a compressed package to one or more Service Fabric clusters, as needed, using [Copy-ServiceFabricApplicationPackage](/powershell/module/servicefabric/copy-servicefabricapplicationpackage)