From 8797457d51c64e4b439185dadddb7838dba6a9ab Mon Sep 17 00:00:00 2001 From: Owen Diehl Date: Wed, 2 Sep 2020 13:12:27 -0400 Subject: [PATCH 1/2] fixes some doc links --- docs/sources/storage/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/sources/storage/_index.md b/docs/sources/storage/_index.md index 9c8f3b14c885..527c7de6bd3e 100644 --- a/docs/sources/storage/_index.md +++ b/docs/sources/storage/_index.md @@ -138,7 +138,7 @@ Note, there are a few other DynamoDB provisioning options including DynamoDB aut When a new schema is released and you want to gain the advantages it provides, you can! Loki can transparently query & merge data from across schema boundaries so there is no disruption of service and upgrading is easy. -First, you'll want to create a new [period_config](./configuration/README.md#period_config) entry in your [schema_config](./configuration/README#schema_config). The important thing to remember here is to set this at some point in the _future_ and then roll out the config file changes to Loki. This allows the table manager to create the required table in advance of writes and will ensure that existing data isn't queried as if it adheres to the new schema. +First, you'll want to create a new [period_config](../configuration#period_config) entry in your [schema_config](../configuration#schema_config). The important thing to remember here is to set this at some point in the _future_ and then roll out the config file changes to Loki. This allows the table manager to create the required table in advance of writes and will ensure that existing data isn't queried as if it adheres to the new schema. As an example, let's say it's 2020-07-14 and we want to start using the `v11` schema on the 20th: ```yaml From 9121e45d6af30b7e87e7ec27b78d14ec6a35490b Mon Sep 17 00:00:00 2001 From: Owen Diehl Date: Wed, 2 Sep 2020 13:17:26 -0400 Subject: [PATCH 2/2] Update docs/sources/storage/_index.md Co-authored-by: Diana Payton <52059945+oddlittlebird@users.noreply.github.com> --- docs/sources/storage/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/sources/storage/_index.md b/docs/sources/storage/_index.md index 527c7de6bd3e..d4f9a9d54ee2 100644 --- a/docs/sources/storage/_index.md +++ b/docs/sources/storage/_index.md @@ -138,7 +138,7 @@ Note, there are a few other DynamoDB provisioning options including DynamoDB aut When a new schema is released and you want to gain the advantages it provides, you can! Loki can transparently query & merge data from across schema boundaries so there is no disruption of service and upgrading is easy. -First, you'll want to create a new [period_config](../configuration#period_config) entry in your [schema_config](../configuration#schema_config). The important thing to remember here is to set this at some point in the _future_ and then roll out the config file changes to Loki. This allows the table manager to create the required table in advance of writes and will ensure that existing data isn't queried as if it adheres to the new schema. +First, you'll want to create a new [period_config](../configuration#period_config) entry in your [schema_config](../configuration.md#schema_config). The important thing to remember here is to set this at some point in the _future_ and then roll out the config file changes to Loki. This allows the table manager to create the required table in advance of writes and ensures that existing data isn't queried as if it adheres to the new schema. As an example, let's say it's 2020-07-14 and we want to start using the `v11` schema on the 20th: ```yaml