Merge pull request #12788 from pkcsf/patch-3

Updating the Warning

Author: ktoliver

articles/service-fabric/service-fabric-cluster-capacity.md

@@ -58,7 +58,7 @@ The Service Fabric system services (for example, the Cluster Manager service or
 * The **minimum size of VMs** for the primary node type is determined by the **durability tier** you choose. The default durability tier is Bronze. See [The durability characteristics of the cluster](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-capacity#the-durability-characteristics-of-the-cluster) for more details.  
 * The **minimum number of VMs** for the primary node type is determined by the **reliability tier** you choose. The default reliability tier is Silver. See [The reliability characteristics of the cluster](https://docs.microsoft.com/azure/service-fabric/service-fabric-cluster-capacity#the-reliability-characteristics-of-the-cluster) for more details.  
 
-From the Azure Resource Manager template, the primary node type is configured with the `isPrimary` attribute under the [node type definition](https://docs.microsoft.com/en-us/azure/templates/microsoft.servicefabric/clusters#nodetypedescription-object).
+From the Azure Resource Manager template, the primary node type is configured with the `isPrimary` attribute under the [node type definition](https://docs.microsoft.com/azure/templates/microsoft.servicefabric/clusters#nodetypedescription-object).
 
 ### Non-primary node type
 
@@ -106,10 +106,6 @@ Use Silver or Gold durability for all node types that host stateful services you
 - Adopt safer ways to make a VM SKU change (Scale up/down): Changing the VM SKU of a virtual machine scale set is inherently an unsafe operation and so should be avoided if possible. Here is the process you can follow to avoid common issues.
 	- **For non-primary node types:** It is recommended that you create new virtual machine scale set, modify the service placement constraint to include the new virtual machine scale set/node type and then reduce the old virtual machine scale set instance count to 0, one node at a time (this is to make sure that removal of the nodes do not impact the reliability of the cluster).
 	- **For the primary node type:** Our recommendation is that you do not change VM SKU of the primary node type. Changing of the primary node type SKU is not supported. If the reason for the new SKU is capacity, we recommend adding more instances. If that not possible, create a new cluster and [restore application state](service-fabric-reliable-services-backup-restore.md) (if applicable) from your old cluster. You do not need to restore any system service state, they are recreated when you deploy your applications to your new cluster. If you were just running stateless applications on your cluster, then all you do is deploy your applications to the new cluster, you have nothing to restore. If you decide to go the unsupported route and want to change the VM SKU, then make modifications to the virtual machine scale set Model definition to reflect the new SKU. If your cluster has only one node type, then make sure that all your stateful applications respond to all [Service replica lifecycle events](service-fabric-reliable-services-lifecycle.md) (like replica in build is stuck) in a timely fashion and that your service replica rebuild duration is less than five minutes (for Silver durability level). 
-
-    > [!WARNING]
-    > Changing the VM SKU Size for virtual machine scale sets not running at least Silver durability is not recommended. Changing VM SKU Size is a data-destructive in-place infrastructure operation. Without at least some ability to delay or monitor this change, it is possible that the operation can cause data loss for stateful services or cause other unforeseen operational issues, even for stateless workloads. 
-    > 
 
 - Maintain a minimum count of five nodes for any virtual machine scale set that has durability level of Gold or Silver enabled.
 - Each VM scale set with durability level Silver or Gold must map to its own node type in the Service Fabric cluster. Mapping multiple VM scale sets to a single node type will prevent coordination between the Service Fabric cluster and the Azure infrastructure from working properly.