updated the indentation

content/en/docs/concepts/policy/limit-range.md

@@ -29,12 +29,14 @@ each applicable object kind (such as Pod or {{< glossary_tooltip text="Persisten
 A _LimitRange_ provides constraints that can:
 
 - Enforce minimum and maximum compute resources usage per Pod or Container in a namespace.
-- Enforce minimum and maximum storage request per {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} in a namespace.
+- Enforce minimum and maximum storage request per
+  {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} in a namespace.
 - Enforce a ratio between request and limit for a resource in a namespace.
-- Set default request/limit for compute resources in a namespace and automatically inject them to Containers at runtime.
+- Set default request/limit for compute resources in a namespace and automatically
+  inject them to Containers at runtime.
 
-A LimitRange is enforced in a particular namespace when there is a
-LimitRange object in that namespace.
+Kubernetes constrains resource allocations to Pods in a particular namespace
+whenever there is at least one LimitRange object in that namespace.
 
 The name of a LimitRange object must be a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
@@ -42,30 +44,38 @@ The name of a LimitRange object must be a valid
 ## Constraints on resource limits and requests
 
 - The administrator creates a LimitRange in a namespace.
-- Users create (or try to create) objects in that namespace, such as Pods or PersistentVolumeClaims.
-- First, the LimitRange admission controller applies default request and limit values for all Pods (and their containers) that do not set compute resource requirements.
-- Second, the LimitRange tracks usage to ensure it does not exceed resource minimum, maximum and ratio defined in any LimitRange present in the namespace.
-- If you attempt to create or update an object (Pod or PersistentVolumeClaim) that violates a LimitRange constraint,
-your request to the API server will fail with an HTTP status code `403 Forbidden` and a message explaining the constraint that has been violated.
-- If you add a LimitRange in a namespace that applies to compute-related resources such as `cpu` and `memory`, you must specify
-requests or limits for those values. Otherwise, the system may reject Pod creation.
+- Users create (or try to create) objects in that namespace, such as Pods or
+  PersistentVolumeClaims.
+- First, the LimitRange admission controller applies default request and limit values
+  for all Pods (and their containers) that do not set compute resource requirements.
+- Second, the LimitRange tracks usage to ensure it does not exceed resource minimum,
+  maximum and ratio defined in any LimitRange present in the namespace.
+- If you attempt to create or update an object (Pod or PersistentVolumeClaim) that violates
+  a LimitRange constraint, your request to the API server will fail with anHTTP status
+  code `403 Forbidden` and a message explaining the constraint that has been violated.
+- If you add a LimitRange in a namespace that applies to compute-related resources
+  such as `cpu` and `memory`, you must specify requests or limits for those values.
+  Otherwise, the system may reject Pod creation.
 - LimitRange validations occur only at Pod admission stage, not on running Pods.
-If you add or modify a LimitRange, the Pods that already exist in that namespace continue unchanged.
-- If two or more LimitRange objects exist in the namespace, it is not deterministic which default value will be applied.
+  If you add or modify a LimitRange, the Pods that already exist in that namespace
+  continue unchanged.
+- If two or more LimitRange objects exist in the namespace, it is not deterministic
+  which default value will be applied.
 
 ## LimitRange and admission checks for Pods
 
-A LimitRange does **not** check the consistency of the default values it applies. This means that a default value for
-the _limit_ that is set by LimitRange may be less than the _request_ value specified for the container in the spec
-that a client submits to the API server. If that happens, the final Pod will not be schedulable.
+A LimitRange does **not** check the consistency of the default values it applies.
+This means that a default value for the _limit_ that is set by LimitRange may be
+less than the _request_ value specified for the container in the spec that a client
+submits to the API server. If that happens, the final Pod will not be schedulable.
 
 For example, you define a LimitRange with below manifest:
 {{< note >}}
 The following examples operate within the default namespace of your cluster, as the namespace
 parameter is undefined and the LimitRange scope is limited to the namespace level.
-This implies that any references or operations within these examples will interact with elements
-within the default namespace of your cluster. You can override the operating namespace
-by configuring namespace in the `metadata.namespace` field.
+This implies that any references or operations within these examples will interact
+with elements within the default namespace of your cluster. You can override the
+operating namespace by configuring namespace in the `metadata.namespace` field.
 {{< /note >}}
 
 {{% code_sample file="concepts/policy/limit-range/problematic-limit-range.yaml" %}}
@@ -79,7 +89,8 @@ then that Pod will not be scheduled, failing with an error similar to:
 Pod "example-conflict-with-limitrange-cpu" is invalid: spec.containers[0].resources.requests: Invalid value: "700m": must be less than or equal to cpu limit
 ```
 
-If you set both `request` and `limit`, then that new Pod will be scheduled successfully even with the same LimitRange in place:
+If you set both `request` and `limit`, then that new Pod will be scheduled successfully
+even with the same LimitRange in place:
 
 {{% code_sample file="concepts/policy/limit-range/example-no-conflict-with-limitrange-cpu.yaml" %}}
 
@@ -87,11 +98,15 @@ If you set both `request` and `limit`, then that new Pod will be scheduled succe
 
 Examples of policies that could be created using LimitRange are:
 
-- In a 2 node cluster with a capacity of 8 GiB RAM and 16 cores, constrain Pods in a namespace to request 100m of CPU with a max limit of 500m for CPU and request 200Mi for Memory with a max limit of 600Mi for Memory.
-- Define default CPU limit and request to 150m and memory default request to 300Mi for Containers started with no cpu and memory requests in their specs.
+- In a 2 node cluster with a capacity of 8 GiB RAM and 16 cores, constrain Pods in a
+  namespace to request 100m of CPU with a max limit of 500m for CPU and request 200Mi
+  for Memory with a max limit of 600Mi for Memory.
+- Define default CPU limit and request to 150m and memory default request to 300Mi for
+  Containers started with no cpu and memory requests in their specs.
 
-In the case where the total limits of the namespace is less than the sum of the limits of the Pods/Containers,
-there may be contention for resources. In this case, the Containers or Pods will not be created.
+In the case where the total limits of the namespace is less than the sum of the limits
+of the Pods/Containers, there may be contention for resources. In this case, the
+Containers or Pods will not be created.
 
 Neither contention nor changes to a LimitRange will affect already created resources.
 
@@ -106,4 +121,5 @@ For examples on using limits, see:
 - [how to configure minimum and maximum Storage consumption per namespace](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
 - a [detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/).
 
-Refer to the [LimitRanger design document](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md) for context and historical information.
+Refer to the [LimitRanger design document](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md)
+for context and historical information.