3 files changed, 116 insertions, 7 deletions
diff --git a/doc/drafts/admin-api.md b/doc/book/reference-manual/admin-api.md
index b35a87f1..a891da07 100644
--- a/doc/drafts/admin-api.md
+++ b/doc/book/reference-manual/admin-api.md
@@ -1,18 +1,41 @@
-# Specification of Garage's administration API
++++
+title = "Specification of Garage's administration API"
+weight = 16
++++
 
+The Garage administration API is accessible through a dedicated server whose
+listen address is specified in the `[admin]` section of the configuration
+file (see [configuration file
+reference](@/documentation/reference-manual/configuration.md))
 
 **WARNING.** At this point, there is no comittement to stability of the APIs described in this document.
 We will bump the version numbers prefixed to each API endpoint at each time the syntax
 or semantics change, meaning that code that relies on these endpoint will break
 when changes are introduced.
 
+The Garage administration API was introduced in version 0.7.2, this document
+does not apply to older versions of Garage.
+
 
 ## Access control
 
 The admin API uses two different tokens for acces control, that are specified in the config file's `[admin]` section:
 
-- `metrics_token`: the token for accessing the Metrics endpoint (if this token is not set in the config file, the Metrics endpoint can be accessed without access control);
-- `admin_token`: the token for accessing all of the other administration endpoints (if this token is not set in the config file, access to these endpoints is disabled entirely).
+- `metrics_token`: the token for accessing the Metrics endpoint (if this token
+  is not set in the config file, the Metrics endpoint can be accessed without
+  access control);
+
+- `admin_token`: the token for accessing all of the other administration
+  endpoints (if this token is not set in the config file, access to these
+  endpoints is disabled entirely).
+
+These tokens are used as simple HTTP bearer tokens. In other words, to
+authenticate access to an admin API endpoint, add the following HTTP header
+to your request:
+
+```
+Authorization: Bearer <token>
+```
 
 ## Administration API endpoints
 
diff --git a/doc/book/reference-manual/configuration.md b/doc/book/reference-manual/configuration.md
index bb04650c..65381f46 100644
--- a/doc/book/reference-manual/configuration.md
+++ b/doc/book/reference-manual/configuration.md
@@ -10,6 +10,7 @@ metadata_dir = "/var/lib/garage/meta"
 data_dir = "/var/lib/garage/data"
 
 block_size = 1048576
+block_manager_background_tranquility = 2
 
 replication_mode = "3"
 
@@ -47,6 +48,8 @@ root_domain = ".web.garage"
 
 [admin]
 api_bind_addr = "0.0.0.0:3903"
+metrics_token = "cacce0b2de4bc2d9f5b5fdff551e01ac1496055aed248202d415398987e35f81"
+admin_token = "ae8cb40ea7368bbdbb6430af11cca7da833d3458a5f52086f4e805a570fb5c2a"
 trace_sink = "http://localhost:4317"
 ```
 
@@ -84,6 +87,17 @@ files will remain available. This however means that chunks from existing files
 will not be deduplicated with chunks from newly uploaded files, meaning you
 might use more storage space that is optimally possible.
 
+### `block_manager_background_tranquility`
+
+This parameter tunes the activity of the background worker responsible for
+resyncing data blocks between nodes. The higher the tranquility value is set,
+the more the background worker will wait between iterations, meaning the load
+on the system (including network usage between nodes) will be reduced. The
+minimal value for this parameter is `0`, where the background worker will
+allways work at maximal throughput to resynchronize blocks. The default value
+is `2`, where the background worker will try to spend at most 1/3 of its time
+working, and 2/3 sleeping in order to reduce system load.
+
 ### `replication_mode`
 
 Garage supports the following replication modes:
@@ -326,10 +340,24 @@ Garage has a few administration capabilities, in particular to allow remote moni
 ### `api_bind_addr`
 
 If specified, Garage will bind an HTTP server to this port and address, on
-which it will listen to requests for administration features. Currently,
-this endpoint only exposes Garage metrics in the Prometheus format at
-`/metrics`. This endpoint is not authenticated. In the future, bucket and
-access key management might be possible by REST calls to this endpoint.
+which it will listen to requests for administration features.
+See [administration API reference](@/documentation/reference-manual/admin-api.md) to learn more about these features.
+
+### `metrics_token` (since version 0.7.2)
+
+The token for accessing the Metrics endpoint. If this token is not set in
+the config file, the Metrics endpoint can be accessed without access
+control.
+
+You can use any random string for this value. We recommend generating a random token with `openssl rand -hex 32`.
+
+### `admin_token` (since version 0.7.2)
+
+The token for accessing all of the other administration endpoints.  If this
+token is not set in the config file, access to these endpoints is disabled
+entirely.
+
+You can use any random string for this value. We recommend generating a random token with `openssl rand -hex 32`.
 
 ### `trace_sink`
 
diff --git a/doc/book/reference-manual/k2v.md b/doc/book/reference-manual/k2v.md
new file mode 100644
index 00000000..742e4309
--- /dev/null
+++ b/doc/book/reference-manual/k2v.md
@@ -0,0 +1,58 @@
++++
+title = "K2V"
+weight = 30
++++
+
+Starting with version 0.7.2, Garage introduces an optionnal feature, K2V,
+which is an alternative storage API designed to help efficiently store
+many small values in buckets (in opposition to S3 which is more designed
+to store large blobs).
+
+K2V is currently disabled at compile time in all builds, as the
+specification is still subject to changes. To build a Garage version with
+K2V, the Cargo feature flag `k2v` must be activated.  Special builds with
+the `k2v` feature flag enabled can be obtained from our download page under
+"Extra builds": such builds can be identified easily as their tag name ends
+with `-k2v` (example: `v0.7.2-k2v`).
+
+The specification of the K2V API can be found
+[here](https://git.deuxfleurs.fr/Deuxfleurs/garage/src/branch/k2v/doc/drafts/k2v-spec.md).
+This document also includes a high-level overview of K2V's design.
+
+The K2V API uses AWSv4 signatures for authentification, same as the S3 API.
+The AWS region used for signature calculation is always the same as the one
+defined for the S3 API in the config file.
+
+## Enabling and using K2V
+
+To enable K2V, download and run a build that has the `k2v` feature flag
+enabled, or produce one yourself. Then, add the following section to your
+configuration file:
+
+```toml
+[k2v_api]
+api_bind_addr = "<ip>:<port>"
+```
+
+Please select a port number that is not already in use by another API
+endpoint (S3 api, admin API) or by the RPC server.
+
+We provide an early-stage K2V client library for Rust which can be imported by adding the following to your `Cargo.toml` file:
+
+```toml
+k2v-client = { git = "https://git.deuxfleurs.fr/Deuxfleurs/garage.git" }
+```
+
+There is also a simple CLI utility which can be built from source in the
+following way:
+
+```sh
+git clone https://git.deuxfleurs.fr/Deuxfleurs/garage.git
+cd garage/src/k2v-client
+cargo build --features cli --bin k2v-cli
+```
+
+The CLI utility is self-documented, run `k2v-cli --help` to learn how to use
+it. There is also a short README.md in the `src/k2v-client` folder with some
+instructions.
+