Update service-fabric-patch-orchestration-application.md

Author: itechedit

articles/service-fabric/service-fabric-patch-orchestration-application.md

@@ -25,13 +25,13 @@ ms.author: brkhande
 > As of April 30, 2019, Patch Orchestration Application version 1.2.* is no longer supported. Be sure to upgrade to the latest version.
 
 
-Getting [automatic OS image upgrades on your virtual machine scale set](https://docs.microsoft.com/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-upgrade) is the best practice for keeping your operating system patched in Azure. Patch Orchestration Application (POA) is a wrapper around the Azure Service Fabric Repair Manager  service, which enables configuration-based OS patch scheduling for non-Azure hosted clusters. POA isn't required for non-Azure hosted clusters, but scheduling patch installation by update domain is required to patch Service Fabric cluster hosts without downtime.
+Getting [automatic OS image upgrades on your virtual machine scale set](https://docs.microsoft.com/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-upgrade) is the best practice for keeping your operating system patched in Azure. Patch Orchestration Application (POA) is a wrapper around the Azure Service Fabric Repair Manager service, which enables configuration-based OS patch scheduling for non-Azure hosted clusters. POA isn't required for non-Azure hosted clusters, but scheduling patch installation by update domain is required to patch Service Fabric cluster hosts without incurring downtime.
 
-POA is a Service Fabric application that automates operating system patching on a Service Fabric cluster without downtime.
+POA is a Service Fabric application that automates operating system patching on a Service Fabric cluster without incurring downtime.
 
 POA provides the following features:
 
-- **Automatic operating system update installation**. Operating system updates are automatically downloaded and installed. Cluster nodes are rebooted as needed without cluster downtime.
+- **Automatic operating system update installation**. Operating system updates are automatically downloaded and installed. Cluster nodes are rebooted as needed without incurring cluster downtime.
 
 - **Cluster-aware patching and health integration**. While POA is applying updates, it monitors the health of the cluster nodes. Cluster nodes are updated one node at a time or one update domain at a time. If the health of the cluster goes down because of the patching process, patching is stopped to prevent aggravating the problem.
 
@@ -159,7 +159,7 @@ You can configure POA behavior to meet your needs. Override the default values b
 | WUOperationTimeOutInMinutes | Int <br>(Default: *90*)                   | Specifies the timeout for any Windows Update operation (search or download or install). If the operation is not completed within the specified timeout, it is aborted.       |
 | WURescheduleCount     | Int <br> (Default: *5*)                  | The maximum number of times the service reschedules the Windows update if an operation fails persistently.          |
 | WURescheduleTimeInMinutes | Int <br>(Default: *30*) | The interval at which the service reschedules the Windows updates if failure persists. |
-| WUFrequency           | Comma-separated string (Default: *Weekly, Wednesday, 7:00:00*)     | The frequency for installing Windows updates. The format and possible values are: <br>&nbsp;&nbsp;- Monthly: DD, HH:MM:SS (for example, *Monthly, 5,12:22:32*)<br>Permitted values for field DD (day) are numbers from 1 through 28 and "last". <br> &nbsp;&nbsp;- Weekly, DAY, HH:MM:SS (for example, *Weekly, Tuesday, 12:22:32*)  <br> &nbsp;&nbsp;- Daily, HH:MM:SS (for example, *Daily, 12:22:32*)  <br> &nbsp;&nbsp;-  *None* indicates that Windows updates shouldn't be done.  <br><br> Note that times are in UTC.|
+| WUFrequency           | Comma-separated string (Default: *Weekly, Wednesday, 7:00:00*)     | The frequency for installing Windows updates. The format and possible values are: <br>&nbsp;&nbsp;- Monthly: DD, HH:MM:SS (for example, *Monthly, 5,12:22:32*)<br>Permitted values for field DD (day) are numbers from 1 through 28 and "last". <br> &nbsp;&nbsp;- Weekly, DAY, HH:MM:SS (for example, *Weekly, Tuesday, 12:22:32*)  <br> &nbsp;&nbsp;- Daily, HH:MM:SS (for example, *Daily, 12:22:32*)  <br> &nbsp;&nbsp;-  *None* indicates that Windows updates shouldn't be done.  <br><br> Times are in UTC.|
 | AcceptWindowsUpdateEula | Boolean <br>(Default: *true*) | By setting this flag, the application accepts the End-User License Agreement for Windows Update on behalf of the owner of the machine.              |
 
 > [!TIP]
@@ -276,9 +276,9 @@ To help you understand how updates proceed on a node, let's go step by step:
 
 1. After the updates are downloaded, the Node Agent NTService creates a corresponding repair task for the node with the name *POS___\<unique_id>*. You can view these repair tasks by using the [Get-ServiceFabricRepairTask](https://docs.microsoft.com/powershell/module/servicefabric/get-servicefabricrepairtask?view=azureservicefabricps) cmdlet or using SFX in the node details section. After the repair task is created, it quickly moves to [*Claimed* state](https://docs.microsoft.com/dotnet/api/system.fabric.repair.repairtaskstate?view=azure-dotnet).
 
-1. The Coordinator Service periodically looks for repair tasks in *Claimed* state and then updates them to *Preparing* state based on TaskApprovalPolicy. If TaskApprovalPolicy is configured to be NodeWise, a repair task corresponding to a node is prepared only if there is no other repair task currently in *Preparing*, *Approved*, *Executing*, or *Restoring* state. 
+1. The Coordinator Service periodically looks for repair tasks in *Claimed* state and then updates them to *Preparing* state based on TaskApprovalPolicy. If TaskApprovalPolicy is configured to be NodeWise, a repair task that corresponds to a node is prepared only if no other repair task is currently in *Preparing*, *Approved*, *Executing*, or *Restoring* state. 
 
-   Similarly, in the case of UpgradeWise TaskApprovalPolicy, there are tasks in the preceding states only for nodes that belong to the same update domain. After a repair task is moved to *Preparing* state, the corresponding Service Fabric node is [disabled](https://docs.microsoft.com/powershell/module/servicefabric/disable-servicefabricnode?view=azureservicefabricps) with the intent set to "Restart."
+   Similarly, in the case of UpgradeWise TaskApprovalPolicy, there are tasks in the preceding states only for nodes that belong to the same update domain. After a repair task is moved to *Preparing* state, the corresponding Service Fabric node is [disabled](https://docs.microsoft.com/powershell/module/servicefabric/disable-servicefabricnode?view=azureservicefabricps) with the intent set to *Restart*.
 
    POA versions 1.4.0 and later post events with the ClusterPatchingStatus property on CoordinatorService to display the nodes that are being patched. The updates are installed on _poanode_0, as shown in the following image:
 
@@ -313,7 +313,7 @@ To help you understand how updates proceed on a node, let's go step by step:
       ExecutorSubState | Description
     -- | -- 
       None=1 |  Implies that there wasn't an ongoing operation on the node. The state might be in transition.
-      DownloadCompleted=2 | Implies that the download operation was completed with success, partial failure or failure.
+      DownloadCompleted=2 | Implies that the download operation was completed with success, partial failure, or failure.
       InstallationApproved=3 | Implies that the download operation was completed earlier and Repair Manager has approved the installation.
       InstallationInProgress=4 | Corresponds to the state of execution of the repair task.
       InstallationCompleted=5 | Implies that the installation was completed with success, partial success, or failure.
@@ -376,7 +376,7 @@ A: POA does not install updates while the cluster is unhealthy. Try to bring you
 
 **Q: Should I set TaskApprovalPolicy as "NodeWise" or "UpgradeDomainWise" for my cluster?**
 
-A: The "UpgradeDomainWise" setting speeds up overall cluster patching by patching all the nodes that belong to an update domain in parallel. During the process, nodes that belong to an entire update domain would be unavailable (in [*Disabled* state](https://docs.microsoft.com/dotnet/api/system.fabric.query.nodestatus?view=azure-dotnet#System_Fabric_Query_NodeStatus_Disabled)).
+A: The "UpgradeDomainWise" setting speeds up overall cluster repair by patching in parallel all the nodes that belong to an update domain. During the process, nodes that belong to an entire update domain are unavailable (in [*Disabled* state](https://docs.microsoft.com/dotnet/api/system.fabric.query.nodestatus?view=azure-dotnet#System_Fabric_Query_NodeStatus_Disabled)).
 
 In contrast, the "NodeWise" setting patches only one node at a time, which would imply that overall cluster patching might take longer. However, only one node at most would be unavailable (in *Disabled* state) during the patching process.
 
@@ -412,7 +412,7 @@ A: Some product updates appear only in their own update or patch history. For ex
 
 **Q: Can POA be used to patch my dev cluster (one-node cluster)?**
 
-A: No, POA can't be used to patch a one-node cluster. This limitation is by design, because [Service Fabric system services](https://docs.microsoft.com/azure/service-fabric/service-fabric-technical-overview#system-services) or other customer apps would require downtime. Therefore, patching repair jobs would never get approved by Repair Manager.
+A: No, POA can't be used to patch a one-node cluster. This limitation is by design, because [Service Fabric system services](https://docs.microsoft.com/azure/service-fabric/service-fabric-technical-overview#system-services) or other customer apps would incur downtime. Therefore, patching repair jobs would never get approved by Repair Manager.
 
 **Q: How do I patch cluster nodes on Linux?**
 
@@ -428,7 +428,7 @@ It might also be possible that node patching is blocked because it's stuck in *D
 
 **Q: Why must the node be disabled when POA is patching it?**
 
-A: POA disables the node with a "Restart" intent, which stops or reallocates all the Service Fabric services that are running on the node. POA does this to ensure that applications don't end up using a mix of new and old DLLs, so we recommend not patching a node without disabling it.
+A: POA disables the node with a *Restart* intent, which stops or reallocates all the Service Fabric services that are running on the node. POA does this to ensure that applications don't end up using a mix of new and old DLLs, so we recommend not patching a node without disabling it.
 
 ## Disclaimers