Merge pull request #3058 from hashicorp/d-minor-doc-updates

Minor documentation tweaks

website/source/docs/internals/architecture.html.md

@@ -61,11 +61,12 @@ clarify what is being discussed:
   availability. Servers federate across regions to make Nomad globally aware.
 
 * **Regions and Datacenters** - Nomad models infrastructure as regions and datacenters.
-  Regions may contain multiple datacenters. Servers are assigned to regions and manage
-  all state for the region and make scheduling decisions within that region. Requests that
-  are made between regions are forwarded to the appropriate servers. As an example, you may
-  have a `US` region with the `us-east-1` and `us-west-1` datacenters, connected to the
-  `EU` region with the `eu-fr-1` and `eu-uk-1` datacenters.
+  Regions may contain multiple datacenters. For example, you may have a `US` region with the 
+  `us-east-1` and `us-west-1` datacenters, connected to the `EU` region with the `eu-fr-1` and 
+  `eu-uk-1` datacenters. Servers are assigned to regions and manage all state for the region and 
+  make scheduling decisions within that region. When multiple regions are federated together, 
+  requests that are made between them are forwarded to the appropriate servers. Data is _not_ 
+  replicated between regions.
 
 * **Bin Packing** - Bin Packing is the process of filling bins with items in a way that
   maximizes the utilization of bins. This extends to Nomad, where the clients are "bins"

website/source/docs/vault-integration/index.html.md

@@ -27,7 +27,8 @@ To use the Vault integration, Nomad servers must be provided a Vault token. This
 token can either be a root token or a periodic token with permissions to create
 from a token role. The root token is the easiest way to get started, but we
 recommend a token role based token for production installations. Nomad servers
-will renew the token automatically.
+will renew the token automatically. Note that the Nomad clients do not need to 
+be provided with a Vault token.
 
 ### Root Token Integration
 

website/source/intro/getting-started/jobs.html.md

@@ -250,13 +250,10 @@ changed, another user has modified the job and the plan's results are
 potentially invalid.
 ```
 
-Here we can see the `plan` reports it will ignore two allocations and do one
-create/destroy update which stops the old allocation and starts the new
-allocation because we have changed the version of redis to run.
-
-The reason the plan only reports a single change to occur is because the job
-file has an `update` stanza that tells Nomad to perform rolling updates when the
-job changes at a rate of `max_parallel`, which is set to 1 in the example file.
+The plan output shows us that one allocation will be updated and that the other 
+two will be ignored. This is due to the `max_parallel` setting in the `update` 
+stanza, which is set to 1 to instruct Nomad to perform only a single change at 
+a time.
 
 Once ready, use `run` to push the updated specification: