From 59528043348db09c2b2bfb1c052c01c6080fd4ed Mon Sep 17 00:00:00 2001 From: Paul Banks Date: Thu, 11 Oct 2018 11:38:55 +0100 Subject: [PATCH] Move 1.0.6 upgrade docs that were added in the wrong place --- website/source/docs/upgrade-specific.html.md | 20 ++++++++++++ website/source/docs/upgrading.html.md | 32 +++++--------------- 2 files changed, 28 insertions(+), 24 deletions(-) diff --git a/website/source/docs/upgrade-specific.html.md b/website/source/docs/upgrade-specific.html.md index fb85084c08..f9ea979f3c 100644 --- a/website/source/docs/upgrade-specific.html.md +++ b/website/source/docs/upgrade-specific.html.md @@ -37,6 +37,26 @@ config if they prefer more frequent snapshots. See the documentation for [raft_s and [raft_snapshot_threshold](/docs/agent/options.html#_raft_snapshot_threshold) to understand the trade-offs when tuning these. +## Consul 1.0.7 + +When requesting a specific service (`/v1/health/:service` or +`/v1/catalog/:service` endpoints), the `X-Consul-Index` returned is now the +index at which that _specific service_ was last modified. In version 1.0.6 and +earlier the `X-Consul-Index` returned was the index at which _any_ service was +last modified. See [GH-3890](https://github.com/hashicorp/consul/issues/3890) +for more details. + +During upgrades from 1.0.6 or lower to 1.0.7 or higher, watchers are likely to +see `X-Consul-Index` for these endpoints decrease between blocking calls. + +Consul’s watch feature and `consul-template` should gracefully handle this case. +Other tools relying on blocking service or health queries are also likely to +work; some may require a restart. It is possible external tools could break and +either stop working or continually re-request data without blocking if they +have assumed indexes can never decrease or be reset and/or persist index +values. Please test any blocking query integrations in a controlled environment +before proceeding. + ## Consul 1.0.1 #### Carefully Check and Remove Stale Servers During Rolling Upgrades diff --git a/website/source/docs/upgrading.html.md b/website/source/docs/upgrading.html.md index 52fc572525..4f8764a2be 100644 --- a/website/source/docs/upgrading.html.md +++ b/website/source/docs/upgrading.html.md @@ -25,37 +25,21 @@ fallback to a backward compatible mode of operation otherwise. For most upgrades, the process is simple. Assuming the current version of Consul is A, and version B is released. -1. On each server, install version B of Consul. +1. Check the [version's upgrade notes](/docs/upgrade-specific.html) to ensure + there are no compatibility issues that will affect your workload. If there + are plan accordingly before continuing. -2. Shut down version A, restart with version B. +2. On each server, install version B of Consul. -3. Once all the servers are upgraded, begin a rollout of clients following +3. Shut down version A, restart with version B. + +4. Once all the servers are upgraded, begin a rollout of clients following the same process. -4. Done! You are now running the latest Consul agent. You can verify this +5. Done! You are now running the latest Consul agent. You can verify this by running `consul members` to make sure all members have the latest build and highest protocol version. -## Upgrade from Version 1.0.6 to higher - -In version 1.0.7 and higher, when requesting a specific service -(`/v1/health/:service` or `/v1/catalog/:service` endpoints), the -`X-Consul-Index` returned is now the index at which that specific service was -last modified. -In version 1.0.6 and earlier the X-Consul-Index returned was the index at -which any service was last modified. See -[GH-3890](https://github.com/hashicorp/consul/issues/3890) for more details. - -During upgrades from 1.0.6 or lower to 1.0.7 or higher, watchers are likely to -see `X-Consul-Index` for these endpoints decrease between blocking calls. - -Consul’s watch feature and consul-template should gracefully handle this case. -Other tools relying on blocking service or health queries are also likely to -work; some may require a restart. It is possible external tools could break and -either stop working or continually re-request data without blocking if they -have assumed indexes can never decrease or be reset and/or persist index -values. Please test any blocking query integrations in a controlled environment -before proceeding. ## Backward Incompatible Upgrades