Merge branch 'master' into 15577-ownership-transfer

[arvados.git] / doc / api / storage.html.textile.liquid

diff --git a/doc/api/storage.html.textile.liquid b/doc/api/storage.html.textile.liquid
index 0baaef7b2a10264bb53a6b86d525dc48de91b4f0..aa0ed21b9f86788f880721a63a28cca30e7448f8 100644 (file)
--- a/doc/api/storage.html.textile.liquid
+++ b/doc/api/storage.html.textile.liquid
@@ -1,12 +1,17 @@
 ---
 layout: default
-navsection: api
+navsection: architecture
 title: Storage in Keep
 ...
+{% comment %}
+Copyright (C) The Arvados Authors. All rights reserved.
+
+SPDX-License-Identifier: CC-BY-SA-3.0
+{% endcomment %}
 
 Keep clients are applications such as @arv-get@, @arv-put@ and @arv-mount@ which store and retrieve data from Keep.  In doing so, these programs interact with both the API server (which stores file metadata in form of Collection objects) and individual Keep servers (which store the actual data blocks).
 
-!{{site.baseurl}}/images/Keep_reading_writing_block.svg!
+!(full-width){{site.baseurl}}/images/Keep_reading_writing_block.svg!
 
 h2. Storing a file
 
@@ -18,18 +23,18 @@ h2. Storing a file
 # The client creates a "collection":{{site.baseurl}}/api/methods/collections.html and provides the @manifest_text@
 # The API server accepts the collection after validating the signed tokens (proof of knowledge) for each block.
 
-!{{site.baseurl}}/images/Keep_manifests.svg!
+!(full-width){{site.baseurl}}/images/Keep_manifests.svg!
 
 h2. Fetching a file
 
 # The client requests a @collection@ object including @manifest_text@ from the APIs server
-# The server adds "token signatures" to the @manifest_text@, these signatures are used to prove to Keep servers that the client is permitted to read a given block
+# The server adds "token signatures" to the @manifest_text@ and returns it to the client.
 # The client discovers keep servers (or proxies) using the @accessible@ method on "keep_services":{{site.baseurl}}/api/methods/keep_services.html
 # For each data block, the client chooses the highest priority server using rendezvous hashing, described below.
-# The client sends the data block request to the keep server, including the token signature (proof of access).
+# The client sends the data block request to the keep server, along with the token signature from the API which proves to Keep servers that the client is permitted to read a given block.
 # The server provides the block data after validating the token signature for the block (if the server does not have the block, it returns a 404 and the client tries the next highest priority server)
 
-!{{site.baseurl}}/images/Keep_rendezvous_hashing.svg!
+!(full-width){{site.baseurl}}/images/Keep_rendezvous_hashing.svg!
 
 Each @keep_service@ resource has an assigned uuid.  To determine priority assignments of blocks to servers, for each keep service compute the MD5 sum of the string concatenation of the block locator (hex-coded hash part only) and service uuid, then sort this list in descending order.  Blocks are preferentially placed on servers with the highest weight.