luxolus/open-consul
2
0
Fork 0
Code Issues 1 Pull requests Packages Releases Wiki Activity

Move 1.0.6 upgrade docs that were added in the wrong place

Browse source
This commit is contained in:
Paul Banks 2018-10-11 11:38:55 +01:00
parent 47dd508c80
commit bf634fafee
No known key found for this signature in database
GPG key ID: C25A851A849B8221
2 changed files with 28 additions and 24 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
website/source/docs/upgrade-specific.html.md
View file

@ -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 and [raft_snapshot_threshold](/docs/agent/options.html#_raft_snapshot_threshold) to understand the trade-offs
when tuning these. 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 ## Consul 1.0.1
#### Carefully Check and Remove Stale Servers During Rolling Upgrades #### Carefully Check and Remove Stale Servers During Rolling Upgrades

32
website/source/docs/upgrading.html.md
View file

@ -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 For most upgrades, the process is simple. Assuming the current version of
Consul is A, and version B is released. 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. 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 by running `consul members` to make sure all members have the latest
build and highest protocol version. 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 ## Backward Incompatible Upgrades