[docs-only] Use correct envvar caching names in service readme's

services/eventhistory/README.md

@@ -12,7 +12,7 @@ The `eventhistory` services consumes all events from the configured event system
 
 ## Storing
 
-The `eventhistory` service stores each consumed event via the configured store in `EVENTHISTORY_STORE_TYPE`. Possible stores are:
+The `eventhistory` service stores each consumed event via the configured store in `EVENTHISTORY_STORE`. Possible stores are:
   -   `memory`: Basic in-memory store and the default.
   -   `ocmem`: Advanced in-memory store allowing max size.
   -   `redis`: Stores data in a configured Redis cluster.
@@ -23,7 +23,6 @@ The `eventhistory` service stores each consumed event via the configured store i
 
 1.  Note that in-memory stores are by nature not reboot-persistent.
 2.  Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store apply.
-3.  Events stay in the store for 2 weeks by default. Use `EVENTHISTORY_RECORD_EXPIRY` to adjust this value.
 4.  The eventhistory service can be scaled if not using `in-memory` stores and the stores are configured identically over all instances.
 5.  When using `redis-sentinel`, the Redis master to use is configured via `EVENTHISTORY_STORE_NODES` in the form of `<sentinel-host>:<sentinel-port>/<redis-master>` like `10.10.0.200:26379/mymaster`.
 

services/frontend/README.md

@@ -42,7 +42,7 @@ You can find more details regarding available attributes at the [libre-graph-api
 
 ## Caching
 
-The `frontend` service can use a configured store via `FRONTEND_OCS_RESOURCE_INFO_CACHE_STORE`. Possible stores are:
+The `frontend` service can use a configured store via `FRONTEND_OCS_STAT_CACHE_STORE`. Possible stores are:
   -   `memory`: Basic in-memory store and the default.
   -   `ocmem`: Advanced in-memory store allowing max size.
   -   `redis`: Stores data in a configured Redis cluster.
@@ -54,4 +54,4 @@ The `frontend` service can use a configured store via `FRONTEND_OCS_RESOURCE_INF
 1.  Note that in-memory stores are by nature not reboot-persistent.
 2.  Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store apply.
 3.  The frontend service can be scaled if not using `in-memory` stores and the stores are configured identically over all instances.
-4.  When using `redis-sentinel`, the Redis master to use is configured via `FRONTEND_OCS_RESOURCE_INFO_CACHE_STORE_NODES` in the form of `<sentinel-host>:<sentinel-port>/<redis-master>` like `10.10.0.200:26379/mymaster`.
+4.  When using `redis-sentinel`, the Redis master to use is configured via `FRONTEND_OCS_STAT_CACHE_STORE_NODES` in the form of `<sentinel-host>:<sentinel-port>/<redis-master>` like `10.10.0.200:26379/mymaster`.

services/gateway/README.md

@@ -4,7 +4,7 @@ The gateway service is an ...
 
 ## Caching
 
-The `gateway` service can use a configured store via `GATEWAY_CACHE_STORE`. Possible stores are:
+The `gateway` service can use a configured store via `GATEWAY_STAT_CACHE_STORE`. Possible stores are:
   -   `memory`: Basic in-memory store and the default.
   -   `ocmem`: Advanced in-memory store allowing max size.
   -   `redis`: Stores data in a configured Redis cluster.
@@ -16,4 +16,4 @@ The `gateway` service can use a configured store via `GATEWAY_CACHE_STORE`. Poss
 1.  Note that in-memory stores are by nature not reboot-persistent.
 2.  Though usually not necessary, a database name and a database table can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store apply.
 3.  The gateway service can be scaled if not using `in-memory` stores and the stores are configured identically over all instances.
-4.  When using `redis-sentinel`, the Redis master to use is configured via `GATEWAY_CACHE_STORE_NODES` in the form of `<sentinel-host>:<sentinel-port>/<redis-master>` like `10.10.0.200:26379/mymaster`.
+4.  When using `redis-sentinel`, the Redis master to use is configured via `GATEWAY_STAT_CACHE_STORE_NODES` in the form of `<sentinel-host>:<sentinel-port>/<redis-master>` like `10.10.0.200:26379/mymaster`.

services/postprocessing/README.md

@@ -18,7 +18,7 @@ When all postprocessing steps have completed successfully, the file will be made
 
 The `postprocessing` service needs to store some metadata about uploads to be able to orchestrate post-processing. When running in single binary mode, the default in-memory implementation will be just fine. In distributed deployments it is recommended to use a persistent store, see below for more details.
 
-The `postprocessing` service stores its metadata via the configured store in `POSTPROCESSING_STORE_TYPE`. Possible stores are:
+The `postprocessing` service stores its metadata via the configured store in `POSTPROCESSING_STORE`. Possible stores are:
   -   `memory`: Basic in-memory store and the default.
   -   `ocmem`: Advanced in-memory store allowing max size.
   -   `redis`: Stores data in a configured Redis cluster.

services/userlog/README.md

@@ -8,7 +8,7 @@ Running the `userlog` service without running the `eventhistory` service is not
 
 ## Storing
 
-The `userlog` service persists information via the configured store in `USERLOG_STORE_TYPE`. Possible stores are:
+The `userlog` service persists information via the configured store in `USERLOG_STORE`. Possible stores are:
   -   `memory`: Basic in-memory store and the default.
   -   `ocmem`: Advanced in-memory store allowing max size.
   -   `redis`: Stores data in a configured Redis cluster.