11016: Update BlobSigningTTL config docs.

Arvados-DCO-1.1-Signed-off-by: Tom Clegg <tclegg@veritasgenetics.com>

diff --git a/lib/config/config.default.yml b/lib/config/config.default.yml
index 572a2558eda3c291463e56515c0e1583c2a4adc7..473553e272879742d536edc511033f0456afcedf 100644 (file)
--- a/lib/config/config.default.yml
+++ b/lib/config/config.default.yml
@@ -368,13 +368,26 @@ Clusters:
       # collection's replication_desired attribute is nil.
       DefaultReplication: 2
 
-      # Lifetime (in seconds) of blob permission signatures generated by
-      # the API server. This determines how long a client can take (after
-      # retrieving a collection record) to retrieve the collection data
-      # from Keep. If the client needs more time than that (assuming the
-      # collection still has the same content and the relevant user/token
-      # still has permission) the client can retrieve the collection again
-      # to get fresh signatures.
+      # BlobSigningTTL determines the minimum lifetime of transient
+      # data, i.e., blocks that are not referenced by
+      # collections. Unreferenced blocks exist for two reasons:
+      #
+      # 1) A data block must be written to a disk/cloud backend device
+      # before a collection can be created/updated with a reference to
+      # it.
+      #
+      # 2) Deleting or updating a collection can remove the last
+      # remaining reference to a data block.
+      #
+      # If BlobSigningTTL is too short, long-running
+      # processes/containers will fail when they take too long (a)
+      # between writing blocks and writing collections that reference
+      # them, or (b) between reading collections and reading the
+      # referenced blocks.
+      #
+      # If BlobSigningTTL is too long, data will still be stored long
+      # after the referring collections are deleted, and you will
+      # needlessly fill up disks or waste money on cloud storage.
       #
       # Modifying BlobSigningTTL invalidates existing signatures; see
       # BlobSigningKey note above.

diff --git a/lib/config/generated_config.go b/lib/config/generated_config.go
index 32c101a5a080836aa84a3f2a5d0fc7d244813dda..3766a7c4de84d0d9939bae184d8b5d12361385ae 100644 (file)
--- a/lib/config/generated_config.go
+++ b/lib/config/generated_config.go
@@ -374,13 +374,26 @@ Clusters:
       # collection's replication_desired attribute is nil.
       DefaultReplication: 2
 
-      # Lifetime (in seconds) of blob permission signatures generated by
-      # the API server. This determines how long a client can take (after
-      # retrieving a collection record) to retrieve the collection data
-      # from Keep. If the client needs more time than that (assuming the
-      # collection still has the same content and the relevant user/token
-      # still has permission) the client can retrieve the collection again
-      # to get fresh signatures.
+      # BlobSigningTTL determines the minimum lifetime of transient
+      # data, i.e., blocks that are not referenced by
+      # collections. Unreferenced blocks exist for two reasons:
+      #
+      # 1) A data block must be written to a disk/cloud backend device
+      # before a collection can be created/updated with a reference to
+      # it.
+      #
+      # 2) Deleting or updating a collection can remove the last
+      # remaining reference to a data block.
+      #
+      # If BlobSigningTTL is too short, long-running
+      # processes/containers will fail when they take too long (a)
+      # between writing blocks and writing collections that reference
+      # them, or (b) between reading collections and reading the
+      # referenced blocks.
+      #
+      # If BlobSigningTTL is too long, data will still be stored long
+      # after the referring collections are deleted, and you will
+      # needlessly fill up disks or waste money on cloud storage.
       #
       # Modifying BlobSigningTTL invalidates existing signatures; see
       # BlobSigningKey note above.