From 4b7db544e9a636ce66a0b9dbead33712a3b444e9 Mon Sep 17 00:00:00 2001 From: Jon Benson Date: Wed, 26 Jul 2017 19:33:03 -0700 Subject: [PATCH] Add word --- .../update-strategies/rolling-upgrades.html.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/website/source/docs/operating-a-job/update-strategies/rolling-upgrades.html.md b/website/source/docs/operating-a-job/update-strategies/rolling-upgrades.html.md index 39626772d..152b9eed8 100644 --- a/website/source/docs/operating-a-job/update-strategies/rolling-upgrades.html.md +++ b/website/source/docs/operating-a-job/update-strategies/rolling-upgrades.html.md @@ -16,7 +16,7 @@ updates a job or task group is annotated with a high-level description of the update strategy using the [`update` stanza][update]. Under the hood, Nomad handles limiting parallelism, interfacing with Consul to determine service health and even automatically reverting to an older, healthy job when a -deployment fails. +deployment fails. ## Enabling Rolling Updates @@ -62,7 +62,7 @@ rolling update strategy. Thus when a change is made to the job file that requires new allocations to be made, Nomad will deploy 2 allocations at a time and require that the allocations -running in a healthy state for 30 seconds before deploying more versions of the +be running in a healthy state for 30 seconds before deploying more versions of the new group. By default Nomad determines allocation health by ensuring that all tasks in the @@ -245,7 +245,7 @@ update { healthy_deadline = "10m" # Enable automatically reverting to the last stable job on a failed - # deployment. + # deployment. auto_revert = true } ```