Add UpgradeVersionTag information to docs

This commit is contained in:
Kyle Havlovitz 2017-07-18 14:01:21 -07:00
parent 9268849d11
commit 689c8bc934
No known key found for this signature in database
GPG Key ID: 8A5E6B173056AD6C
3 changed files with 28 additions and 2 deletions

View File

@ -60,6 +60,7 @@ $ curl \
"ServerStabilizationTime": "10s",
"RedundancyZoneTag": "",
"DisableUpgradeMigration": false,
"UpgradeVersionTag": "",
"CreateIndex": 4,
"ModifyIndex": 4
}
@ -110,7 +111,7 @@ The table below shows this endpoint's support for
cluster. Only takes effect if all servers are running Raft protocol version 3
or higher. Must be a duration value such as `30s`.
- `RedundancyZoneTag` `(string: "")` controls the node-meta key to use when
- `RedundancyZoneTag` `(string: "")` - Controls the node-meta key to use when
Autopilot is separating servers into zones for redundancy. Only one server in
each zone can be a voting member at one time. If left blank, this feature will
be disabled.
@ -120,6 +121,10 @@ The table below shows this endpoint's support for
newer-versioned servers have been added to the cluster before promoting any of
them to voters.
- `UpgradeVersionTag` `(string: "")` - Controls the node-meta key to use for
version info when performing upgrade migrations. If left blank, the Consul
version will be used.
### Sample Payload
```json
@ -130,6 +135,7 @@ The table below shows this endpoint's support for
"ServerStabilizationTime": "10s",
"RedundancyZoneTag": "",
"DisableUpgradeMigration": false,
"UpgradeVersionTag": "",
"CreateIndex": 4,
"ModifyIndex": 4
}

View File

@ -46,6 +46,7 @@ MaxTrailingLogs = 250
ServerStabilizationTime = 10s
RedundancyZoneTag = ""
DisableUpgradeMigration = false
UpgradeMigrationTag = ""
```
## set-config
@ -80,6 +81,9 @@ new servers until it can perform a migration. Must be one of `[true|false]`.
* `-redundancy-zone-tag`- (Enterprise-only) Controls the [`-node-meta`](/docs/agent/options.html#_node_meta)
key name used for separating servers into different redundancy zones.
* `-upgrade-version-tag` - (Enterprise-only) Controls the [`-node-meta`](/docs/agent/options.html#_node_meta)
tag to use for version info when performing upgrade migrations. If left blank, the Consul version will be used.
The output looks like this:
```

View File

@ -32,7 +32,8 @@ bootstrapping the cluster:
"max_trailing_logs": 250,
"server_stabilization_time": "10s",
"redundancy_zone_tag": "az",
"disable_upgrade_migration": false
"disable_upgrade_migration": false,
"upgrade_version_tag": ""
}
```
@ -49,6 +50,7 @@ MaxTrailingLogs = 250
ServerStabilizationTime = 10s
RedundancyZoneTag = ""
DisableUpgradeMigration = false
UpgradeVersionTag = ""
$ consul operator autopilot set-config -cleanup-dead-servers=false
Configuration updated!
@ -60,6 +62,7 @@ MaxTrailingLogs = 250
ServerStabilizationTime = 10s
RedundancyZoneTag = ""
DisableUpgradeMigration = false
UpgradeVersionTag = ""
```
## Dead Server Cleanup
@ -200,3 +203,16 @@ node2 127.0.0.1:8703 alive server 0.7.5 2 dc1
node3 127.0.0.1:8803 alive server 0.7.5 2 dc1
node4 127.0.0.1:8203 alive server 0.8.0 2 dc1
```
### Using migrations without a Consul version change
The `UpgradeVersionTag` can be used to override the version information used during
a migration, so that the migration logic can be used for updating the cluster when
changing configuration.
If the `UpgradeVersionTag` setting is set, Consul will use its value to look for a
version in each server's specified [`-node-meta`](/docs/agent/options.html#_node_meta)
tag. For example, if `UpgradeVersionTag` is set to `build`, and `-node-meta build:0.0.2`
is used when starting a server, that server's version will be `0.0.2` when considered in
a migration. The upgrade logic will follow semantic versioning and the version string
must be in the form of either `X`, `X.Y`, or `X.Y.Z`.