Update index.md

updates because of Vale

pages/mesosphere/dcos/services/dcos-monitoring/1.0.0/operations/placement-constraint/index.md

@@ -10,9 +10,9 @@ model: ../../data.yml
 
 # Placement constraints
 
-Placement constraints allow you to customize where a service is deployed in the DC/OS cluster.
+You can use placement constraints to customize where in a DC/OS cluster services are deployed.
 Placement constraints use the [Marathon operators](http://mesosphere.github.io/marathon/docs/constraints.html) syntax.
-For example, `[["hostname", "UNIQUE"]]` ensures that at most one pod instance is deployed per agent.
+For example, `[["hostname", "UNIQUE"]]` ensures that, at most, one pod instance is deployed per agent.
 
 A common task is to specify a list of whitelisted systems to deploy to.
 To achieve this, use the following syntax for the placement constraint:
@@ -21,17 +21,15 @@ To achieve this, use the following syntax for the placement constraint:
 "placement_constraints": "hostname:LIKE:192.168.2.193",
 ```
 
-<p class="message--important"><strong>IMPORTANT: </strong> Be sure to include excess capacity in such a scenario so that if one of the whitelisted systems goes down, there is still enough capacity to repair your service.</p>
+<p class="message--important"><strong>IMPORTANT: </strong> Include excess capacity so that if one of the whitelisted systems goes down, there is still enough capacity to repair your service.</p>
 
-## Updating placement constraints
+## Update placement constraints
 
-Clusters change, and so will your placement constraints.
-However, already-running service pods will **not** be affected by changes in placement constraints.
-This is because altering a placement constraint might invalidate the current placement of a running pod, and the pod will not be relocated automatically, as doing so is a destructive action.
-We recommend using the following procedure to update the placement constraints of a pod:
+Clusters change, and so will your placement constraints. Already-running service pods are **not** impacted by changes in placement constraints. Altering a placement constraint could invalidate the current placement of a running pod, and the pod is not relocated automatically, as doing so is a destructive action.
+To update the placement constraints of a pod:
 
 1. Update the placement constraint definition in the service.
-1. For each affected pod, perform a `pod replace` procedure, one at a time. This will (destructively) move the pod to be in accordance with the new placement constraints.
+1. For each affected pod, perform a `pod replace` procedure, one at a time. This (destructively) moves the pod into accordance with the new placement constraints.
 
 # Grafana server placement constraints