From cdff366f7fa83281d781ef0a39c06e64b3e589d9 Mon Sep 17 00:00:00 2001 From: Rowan Smith <86935689+rowansmithhc@users.noreply.github.com> Date: Sat, 4 Feb 2023 05:58:19 +1100 Subject: [PATCH] docs allow_forwarding_via_token syntax update (#18956) * allow_forwarding_via_token syntax update the example syntax used for `allow_forwarding_via_token` marks the option as an array when it does not need to be, this updates the format on the page to be a code block and removes the square braces * another update to `allow_forwarding_via_token` syntax --- website/content/docs/faq/ssct.mdx | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/website/content/docs/faq/ssct.mdx b/website/content/docs/faq/ssct.mdx index 9225a41e11..a4da089d73 100644 --- a/website/content/docs/faq/ssct.mdx +++ b/website/content/docs/faq/ssct.mdx @@ -64,7 +64,12 @@ With the exception of the prefix changes detailed above that apply to all token There is a new configuration in the replication section as follows: -`replication { allow_forwarding_via_token = ["new_token"] } ` +``` +replication { + allow_forwarding_via_token = "new_token" +} +``` + This configuration allows Vault clusters to be configured so that requests made to performance standbys that don’t yet have the most up-to-date WAL index are forwarded to the active node. Please note that there will be extra load on the active node with this type of configuration. ### Q: Is there anything else I need to consider to achieve consistency, besides upgrading to Vault 1.10? @@ -75,7 +80,13 @@ Yes, there are several considerations to keep in mind, and possibly things that - Ensure that your clients can retry for the best experience. - Starting with Go api version [1.1.0](https://pkg.go.dev/github.com/hashicorp/vault/api@v1.1.0), the Go client library enables automatic retries for 412 errors. By default, retries=2, or use client method [SetMaxRetries](https://pkg.go.dev/github.com/hashicorp/vault/api#Client.SetMaxRetries). Or, you can use the Vault environment variable [VAULT_MAX_RETRIES](/vault/docs/commands#vault_max_retries) to achieve the same result. - If you use a client library other than Go, you may still need to ensure that your client can handle 412 retries in order to achieve consistency. -- If your client cannot retry, you can use the Vault server replication configuration `allow_forwarding_via_token = ["new_token"]` to allow for consistency. As stated earlier, this will incur extra load on the server due to forwarding of requests that don't have the up-to-date WAL-state to the server. +- If your client cannot retry, you can use the Vault server replication configuration `allow_forwarding_via_token` to allow for consistency. As stated earlier, this will incur extra load on the server due to forwarding of requests that don't have the up-to-date WAL-state to the server: + +``` +replication { + allow_forwarding_via_token = "new_token" +} +``` ~> **Note:** If you are generating root tokens or recovery tokens without using the Vault CLI, you will need to modify the OTP length used. refer [here](/vault/docs/upgrading/upgrade-to-1.10.x) for details.