Merge pull request cloudfoundry-attic#6 from savitaashture/issue-1

Fixed documentation errors.

doc/actions.md

@@ -5,7 +5,7 @@ The work performed by a [Task](tasks.md) or [LRP](lrps.md) is expressed in terms
 The following actions are available.  The details are presented below:
 
 - [`RunAction`](#runaction): runs a process in the container
-- [`DownloadAction`](#donwloadaction): fetches an archive (`.tgz` or `.zip`) and extracts it into the container
+- [`DownloadAction`](#downloadaction): fetches an archive (`.tgz` or `.zip`) and extracts it into the container
 - [`UploadAction`](#uploadaction): uploads a single file, in the container, to a URL via POST
 - [`ParallelAction`](#parallelaction): runs multiple actions in parallel.
 - [`SerialAction`](#serialaction): runs multiple actions in order.

doc/api_lrps.md

@@ -59,7 +59,7 @@ This returns an array of [`DesiredLRPResponse`](lrps.md#fetching-desiredlrps) ob
 
 ### Fetching a Specific DesiredLRP
 
-To fetch a DesiredLRP by [`process_guid`](lrps.md#process-guid):
+To fetch a DesiredLRP by [`process_guid`](lrps.md#process_guid):
 
 ```
 GET /v1/desired_lrps/:process_guid

doc/api_tasks.md

@@ -27,7 +27,7 @@ This returns an array of [`TaskResponse`](tasks.md#retreiving-tasks) objects
 
 ### Fetching Tasks by Domain
 
-To fetch all Tasks in a given [`domain`](tasks.md#domain):
+To fetch all Tasks in a given [`domain`](tasks.md#domain-required):
 
 ```
 GET /v1/tasks?domain=domain-name
@@ -37,7 +37,7 @@ This returns an array of [`TaskResponse`](tasks.md#retreiving-tasks) objects
 
 ### Fetching a Specific Task
 
-To fetch a Task by [`task_guid`](tasks.md#task-guid):
+To fetch a Task by [`task_guid`](tasks.md#task_guid-required):
 
 ```
 GET /v1/tasks/:task_guid

doc/environment.md

@@ -26,3 +26,5 @@ These environment variables are *only* provided if the operator deploying Diego
 - `CF_INSTANCE_PORT` the host-side port corresponding to the *first* desired port in the `DesiredLRP` [`ports`](lrps.md#ports) array.
 - `CF_INSTANCE_ADDR` identical to `$CF_INSTANCE_IP:$CF_INSTANCE_PORT`
 - `CF_INSTANCE_PORTS` a list of the form `61012:8080,61013:5000`.  The comma delimited entries are pairs of `host-side-port:container-side-port`.  The container-side ports map onto the `DesiredLRP` [`ports`](lrps.md#ports) array.
+
+[back](README.md)

doc/events.md

@@ -83,3 +83,5 @@ When a new actual LRP is deleted a `ActualLRPRemovedEvent` is emitted. Below the
 ```
 
 The field value of `actual_lrp` will be a `ActualLRPResponse`, which is described in the [LRP API](lrps.md).
+
+[back](README.md)

doc/lrps.md

@@ -1,6 +1,6 @@
 # LRPs: Long Running Processes
 
-Diego can distribute and monitor multiple instances of a Long Running Process (LRP).  These instances are distributed across Diego Cells and restarted automatically if they crash or disappear.  The instances are identical (though each instance is given a unique index (in the range `0, 1, ...N-1`) and a a unique instance guid).
+Diego can distribute and monitor multiple instances of a Long Running Process (LRP).  These instances are distributed across Diego Cells and restarted automatically if they crash or disappear.  The instances are identical (though each instance is given a unique index (in the range `0, 1, ...N-1`) and a unique instance guid).
 
 LRPs are described by providing Diego with a `DesiredLRP`.  The `DesiredLRP` can be thought of as a manifest that describes how an LRP should be executed and monitored.
 
@@ -124,10 +124,10 @@ For more details on the environment variables provided to processes in the conta
 
 #### `cpu_weight` [optional]
 
-To control the CPU shares provided to a container, set `cpu_weight`.  This must be a positive number in the range `1-100`.  The `cpu_weight` enforces a relative fair share of the CPU among containers.  It's best explained with examples.  Consider the following scenarios (we shall assume that each container is running a busy process that is attempting to consumer as many CPU resources as possible):
+To control the CPU shares provided to a container, set `cpu_weight`.  This must be a positive number in the range `1-100`.  The `cpu_weight` enforces a relative fair share of the CPU among containers.  It's best explained with examples.  Consider the following scenarios (we shall assume that each container is running a busy process that is attempting to consume as many CPU resources as possible):
 
 - Two containers, with equal values of `cpu_weight`: both containers will receive equal shares of CPU time.
-- Two containers, one with `cpu_weight=50` the other with `cpu_weight=100`: the latter will get (roughly) 2/3 of the CPU time, the former 1/3.
+- Two containers, one with `cpu_weight=50` the other with `cpu_weight=100`: the later will get (roughly) 2/3 of the CPU time, the former 1/3.
 
 #### `disk_mb` [optional]
 

doc/tasks.md

@@ -103,10 +103,10 @@ For more details on the environment variables provided to processes in the conta
 
 #### `cpu_weight` [optional]
 
-To control the CPU shares provided to a container, set `cpu_weight`.  This must be a positive number in the range `1-100`.  The `cpu_weight` enforces a relative fair share of the CPU among containers.  It's best explained with examples.  Consider the following scenarios (we shall assume that each container is running a busy process that is attempting to consumer as many CPU resources as possible):
+To control the CPU shares provided to a container, set `cpu_weight`.  This must be a positive number in the range `1-100`.  The `cpu_weight` enforces a relative fair share of the CPU among containers.  It's best explained with examples.  Consider the following scenarios (we shall assume that each container is running a busy process that is attempting to consume as many CPU resources as possible):
 
 - Two containers, with equal values of `cpu_weight`: both containers will receive equal shares of CPU time.
-- Two containers, one with `cpu_weight=50` the other with `cpu_weight=100`: the latter will get (roughly) 2/3 of the CPU time, the former 1/3.
+- Two containers, one with `cpu_weight=50` the other with `cpu_weight=100`: the later will get (roughly) 2/3 of the CPU time, the former 1/3.
 
 #### `disk_mb` [optional]
 
@@ -307,7 +307,7 @@ Tasks in Diego undergo a simple lifecycle encoded in the Tasks's state:
 - When the Cell begins to create the container and run the Task action, the Task enters the `RUNNING` state.
 - When the Task completes, the Cell annotates the `TaskResponse` with `failed`, `failure_reason`, and `result`, and puts the Task in the `COMPLETED` state.
 
-At this point it is up to the consumer of Diego to acknowledge and resolve the completed Task.  This can either be done via a completion callback (described [above](#completion_callback_url)) or by [deleting](delete_tasks.md) the Task.  When the Task is being resolved it first enters the `RESOLVING` state and is ultimately removed from Diego.
+At this point it is up to the consumer of Diego to acknowledge and resolve the completed Task.  This can either be done via a completion callback (described [above](#completion_callback_url-optional)) or by [deleting](delete_tasks.md) the Task.  When the Task is being resolved it first enters the `RESOLVING` state and is ultimately removed from Diego.
 
 Diego will automatically reap Tasks that remain unresolved after 2 minutes.