From 564028473059e98a9b6523d79028ed74154ac3b8 Mon Sep 17 00:00:00 2001 From: Rob Genova Date: Fri, 18 Aug 2017 23:16:39 +0000 Subject: [PATCH 1/3] Make it explicit that data is not replicated between regions. --- website/source/docs/internals/architecture.html.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/website/source/docs/internals/architecture.html.md b/website/source/docs/internals/architecture.html.md index 2d4ef4498..8d5864dab 100644 --- a/website/source/docs/internals/architecture.html.md +++ b/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" From 0774bba4fd471c71277f9377af8e1578171206e3 Mon Sep 17 00:00:00 2001 From: Rob Genova Date: Fri, 18 Aug 2017 23:17:20 +0000 Subject: [PATCH 2/3] Clarify that it is not required to set a Vault token on the clients. --- website/source/docs/vault-integration/index.html.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/website/source/docs/vault-integration/index.html.md b/website/source/docs/vault-integration/index.html.md index 2e2cbd078..90ba19932 100644 --- a/website/source/docs/vault-integration/index.html.md +++ b/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 From de36bd7f42bf982b0edc4460428ccc954e0a732a Mon Sep 17 00:00:00 2001 From: Rob Genova Date: Fri, 18 Aug 2017 23:18:20 +0000 Subject: [PATCH 3/3] Reword long-ish sentence. --- website/source/intro/getting-started/jobs.html.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/website/source/intro/getting-started/jobs.html.md b/website/source/intro/getting-started/jobs.html.md index ff290126b..5d8079089 100644 --- a/website/source/intro/getting-started/jobs.html.md +++ b/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: