From 84d2d8dae95e090e38cb736ab3305779df28b95c Mon Sep 17 00:00:00 2001 From: mmattel Date: Sun, 23 Apr 2023 10:02:27 +0200 Subject: [PATCH] [docs-only] Fix texts and typos in README.md files --- docs/helpers/README.md | 3 ++- docs/services/frontend/_index.md | 37 ------------------------------- services/antivirus/README.md | 4 ++-- services/eventhistory/README.md | 8 +++---- services/frontend/README.md | 8 +++++++ services/gateway/README.md | 2 +- services/graph/README.md | 4 ++-- services/ocs/README.md | 4 ++-- services/policies/README.md | 8 +++---- services/postprocessing/README.md | 10 ++++----- services/proxy/README.md | 6 ++--- services/storage-system/README.md | 4 ++-- services/storage-users/README.md | 4 ++-- services/userlog/README.md | 4 ++-- 14 files changed, 39 insertions(+), 67 deletions(-) delete mode 100644 docs/services/frontend/_index.md diff --git a/docs/helpers/README.md b/docs/helpers/README.md index 943bd281e..3f017e117 100644 --- a/docs/helpers/README.md +++ b/docs/helpers/README.md @@ -16,11 +16,12 @@ ## Introduction -`docs/helpers` contains small go programs creating docs by extracting information from the code. The `main.go` program is manually started with `make docs-generate` or via the CI. It calls the other required programs and has three main responsibilities: +`docs/helpers` contains small go programs creating docs by extracting information from the code. The `main.go` program is manually started with `make docs-generate` or via the CI. It calls the other required programs and has these main responsibilities: - Generate docs for envvars in config structs including deprecations if there are any. - Extract and generate docs for `extended` envvars that are not mentioned in config structs (aka "rogue" envvars). - Extract and generate docs for `global` envvars which occur in multiple services. +- Create `docs/service//_index.md` from `service//README.md` files while keeping the existing `_index.md` if the README.md has not been created so far. ## Output Generated diff --git a/docs/services/frontend/_index.md b/docs/services/frontend/_index.md deleted file mode 100644 index b76629264..000000000 --- a/docs/services/frontend/_index.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Frontend -date: 2022-03-02T00:00:00+00:00 -weight: 20 -geekdocRepo: https://github.com/owncloud/ocis -geekdocEditPath: edit/master/docs/services/frontend -geekdocFilePath: _index.md -geekdocCollapseSection: true ---- - -## Abstract - -The frontend service provides multiple HTTP endpoints to translate OCS, archiver and approvider requests into CS3 requests. - -## Table of Contents - -{{< toc-tree >}} - -## OCS - -The OCS endpoint implements the open collaboration services API in a backwards compatible manner. - -### Sharing - -Aggregating share information is one of the most time consuming operations in OCIS. The service fetches a list of either received or created shares and has to stat every resource individually. While stats are fast, the default behavior scales linearly with the number of shares. - -To save network trips the sharing implementation can cache the stat requests with an in memory cache or in redis. It will shorten the response time by the network round-trip overhead at the cost of the API only eventually being updated. - -Setting `FRONTEND_OCS_RESOURCE_INFO_CACHE_TTL=60` would cache the stat info for 60 seconds. Increasing this value makes sense for large deployments with thousands of active users that keep the cache up to date. Low frequency usage scenarios should not expect a noticeable improvement. - -## Archiver - -The archiver endpoint provides bundled downloads of multiple files and folders. - -## Appprovider - -The appprovider endpoint is used to manage available apps that can be used to open different file types. diff --git a/services/antivirus/README.md b/services/antivirus/README.md index 875eee148..09a335229 100644 --- a/services/antivirus/README.md +++ b/services/antivirus/README.md @@ -11,9 +11,9 @@ The antivirus service currently supports [ICAP](https://tools.ietf.org/html/rfc3 - For `icap`, only scanners using the `X-Infection-Found` header are currently supported. - For `clamav` only local sockets can currently be configured. -### Maximum Scan size +### Maximum Scan Size -Several factors can make it necessary to limit the maximum filesize the antivirus service will use for scanning. Use the `ANTIVIRUS_MAX_SCAN_SIZE` environment variable to scan only a given amount of bytes. Obviously, it is recommended to scan the whole file, but several factors like scanner type and version, bandwith, performance issues, etc. might make a limit necessary. +Several factors can make it necessary to limit the maximum filesize the antivirus service will use for scanning. Use the `ANTIVIRUS_MAX_SCAN_SIZE` environment variable to scan only a given amount of bytes. Obviously, it is recommended to scan the whole file, but several factors like scanner type and version, bandwidth, performance issues, etc. might make a limit necessary. ### Infected File Handling diff --git a/services/eventhistory/README.md b/services/eventhistory/README.md index 66b7b1359..31bdd610e 100644 --- a/services/eventhistory/README.md +++ b/services/eventhistory/README.md @@ -4,11 +4,11 @@ The `eventhistory` consumes all events from the configured event system like NAT ## Prerequisites -Running the eventhistory service without an event sytem like NATS is not possible. +Running the eventhistory service without an event system like NATS is not possible. ## Consuming -The `eventhistory` services consumes all events from the configured event sytem. +The `eventhistory` services consumes all events from the configured event system. ## Storing @@ -19,10 +19,10 @@ The `eventhistory` service stores each consumed event via the configured store i - `redis-sentinel`: Stores data in a configured redis sentinel cluster. - `etcd`: Stores data in a configured etcd cluster. - `nats-js`: Stores data using key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store) - - `noop`: Stores nothing. Useful for testing. Not recommended in productive enviroments. + - `noop`: Stores nothing. Useful for testing. Not recommended in production environments. 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 applicapable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store applies. +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 applies. 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 `:/` like `10.10.0.200:26379/mymaster`. diff --git a/services/frontend/README.md b/services/frontend/README.md index c128b5fd4..bb6383f94 100644 --- a/services/frontend/README.md +++ b/services/frontend/README.md @@ -22,6 +22,14 @@ The datagateway endpoint, by default `/data`, forwards file up- and download req The ocs endpoint, by default `/ocs`, implements the ownCloud 10 Open Collaboration Services API by translating it into CS3 API requests. It can handle users, groups, capabilities and also implements the files sharing functionality on top of CS3. The `/ocs/v[12].php/cloud/user/signing-key` is currently handled by the dedicated [ocs](https://github.com/owncloud/ocis/tree/master/services/ocs) service. +### Sharing + +Aggregating share information is one of the most time consuming operations in OCIS. The service fetches a list of either received or created shares and has to stat every resource individually. While stats are fast, the default behavior scales linearly with the number of shares. + +To save network trips the sharing implementation can cache the stat requests with an in memory cache or in redis. It will shorten the response time by the network round-trip overhead at the cost of the API only eventually being updated. + +Setting `FRONTEND_OCS_RESOURCE_INFO_CACHE_TTL=60` would cache the stat info for 60 seconds. Increasing this value makes sense for large deployments with thousands of active users that keep the cache up to date. Low frequency usage scenarios should not expect a noticeable improvement. + ## Scalability While the frontend service does not persist any data it does cache `Stat()` responses and user information. Therefore, multiple instances of this service can be spawned in a bigger deployment like when using container orchestration with Kubernetes, when configuring `FRONTEND_OCS_RESOURCE_INFO_CACHE_TYPE=redis` and the related config options. diff --git a/services/gateway/README.md b/services/gateway/README.md index bd16605b5..e0a197ab9 100644 --- a/services/gateway/README.md +++ b/services/gateway/README.md @@ -10,5 +10,5 @@ The `gateway` service can use a configured store via `GATEWAY_CACHE_STORE`. Poss - `etcd`: Stores data in a configured etcd cluster. 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 applicapable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store applies. +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 applies. 3. The gateway service can be scaled if not using `in-memory` stores and the stores are configured identically over all instances. diff --git a/services/graph/README.md b/services/graph/README.md index 6cfa65fe2..84b3aab67 100644 --- a/services/graph/README.md +++ b/services/graph/README.md @@ -24,10 +24,10 @@ The `graph` service can use a configured store via `GRAPH_STORE_TYPE`. Possible - `redis-sentinel`: Stores data in a configured redis sentinel cluster. - `etcd`: Stores data in a configured etcd cluster. - `nats-js`: Stores data using key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store) - - `noop`: Stores nothing. Useful for testing. Not recommended in productive enviroments. + - `noop`: Stores nothing. Useful for testing. Not recommended in production environments. 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 applicapable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store applies. +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 applies. 3. The graph 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 `GRAPH_CACHE_STORE_NODES` in the form of `:/` like `10.10.0.200:26379/mymaster`. diff --git a/services/ocs/README.md b/services/ocs/README.md index 12e8ff629..5e2135ab4 100644 --- a/services/ocs/README.md +++ b/services/ocs/README.md @@ -11,9 +11,9 @@ The `ocs` service can use a configured store via `OCS_STORE_TYPE`. Possible stor - `redis-sentinel`: Stores data in a configured redis sentinel cluster. - `etcd`: Stores data in a configured etcd cluster. - `nats-js`: Stores data using key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store) - - `noop`: Stores nothing. Useful for testing. Not recommended in productive enviroments. + - `noop`: Stores nothing. Useful for testing. Not recommended in production environments. 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 applicapable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store applies. +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 applies. 3. The ocs 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 `OCS_CACHE_STORE_NODES` in the form of `:/` like `10.10.0.200:26379/mymaster`. diff --git a/services/policies/README.md b/services/policies/README.md index b0911a28e..67b04f16d 100644 --- a/services/policies/README.md +++ b/services/policies/README.md @@ -86,7 +86,7 @@ proxy: query: data.proxy.granted ``` -The same can be achieved by setting the following evironment variable: +The same can be achieved by setting the following environment variable: ```yaml PROXY_POLICIES_QUERY=data.proxy.granted @@ -100,13 +100,13 @@ policies: query: data.postprocessing.granted ``` -The same can be achieved by setting the following evironment variable: +The same can be achieved by setting the following environment variable: ```yaml POLICIES_POSTPROCESSING_QUERY=data.postprocessing.granted ``` -As soon as that query is configured, the postprocessing service must be informed to use the policies step by setting the environment variable: +As soon as that query is configured, the postprocessing service must be informed to use the policies step by setting the environment variable: ```yaml POSTPROCESSING_STEPS=policies @@ -116,7 +116,7 @@ Note that additional steps can be configured and their position in the list defi ## Rego Key Match -To identify available keys for OPA, you need to look at [engine.go](https://github.com/owncloud/ocis/blob/master/services/policies/pkg/engine/engine.go) and the [policies.swagger.json](https://github.com/owncloud/ocis/blob/master/protogen/gen/ocis/services/policies/v0/policies.swagger.json) file. Note that which keys are avaialble depends from which module it is used. +To identify available keys for OPA, you need to look at [engine.go](https://github.com/owncloud/ocis/blob/master/services/policies/pkg/engine/engine.go) and the [policies.swagger.json](https://github.com/owncloud/ocis/blob/master/protogen/gen/ocis/services/policies/v0/policies.swagger.json) file. Note that which keys are available depends on from which module it is used. ## Example Policies diff --git a/services/postprocessing/README.md b/services/postprocessing/README.md index 50f35ee29..bdcdef577 100644 --- a/services/postprocessing/README.md +++ b/services/postprocessing/README.md @@ -10,13 +10,13 @@ To use the postprocessing service, an event system needs to be configured for al The storageprovider service (`storage-users`) can be configured to initiate asynchronous postprocessing by setting the `STORAGE_USERS_OCIS_ASYNC_UPLOADS` environment variable to `true`. If this is the case, postprocessing will get initiated *after* uploading a file and all bytes have been received. -The `postprocessing` service will then coordinate configured postprocessing steps like scanning the file for viruses. During postprocessing, the file will be in a `processing state` where only a limited set of actions are available. Note that this processing state excludes file accessability by users. +The `postprocessing` service will then coordinate configured postprocessing steps like scanning the file for viruses. During postprocessing, the file will be in a `processing state` where only a limited set of actions are available. Note that this processing state excludes file accessibility by users. When all postprocessing steps have completed successfully, the file will be made accessible for users. ## Additional Prerequisites for the Postprocessing Service -When postprocessing has been enabled, configuring any postprocessing step will require the requested services to be enabled and pre-configured. For example, to use the `virusscan` step, one needs to have an enabled and configured `antivirus` service. +When postprocessing has been enabled, configuring any postprocessing step will require the requested services to be enabled and pre-configured. For example, to use the `virusscan` step, one needs to have an enabled and configured `antivirus` service. ## Postprocessing Steps @@ -28,7 +28,7 @@ To enable virus scanning as a postprocessing step after uploading a file, the en ### Delay -Though this is for development purposes only and NOT RECOMMENDED on production systems, setting the environment variable `POSTPROCESSING_DELAY` to a duration not equal to zero will add a delay step with the configured amount of time. ocis will continue postprocessing the file after the configured delay. Use the enviroment variable `POSTPROCESSING_STEPS` and the keyword `delay` if you have multiple postprocessing steps and want to define their order. If `POSTPROCESSING_DELAY` is set but the keyword `delay` is not contained in `POSTPROCESSING_STEPS`, it will be processed as last postprocessing step without being listed there. In this case, a log entry will be written on service startup to notify the admin about that situation. That log entry can be avoided by adding the keyword `delay` to `POSTPROCESSING_STEPS`. +Though this is for development purposes only and NOT RECOMMENDED on production systems, setting the environment variable `POSTPROCESSING_DELAY` to a duration not equal to zero will add a delay step with the configured amount of time. ocis will continue postprocessing the file after the configured delay. Use the environment variable `POSTPROCESSING_STEPS` and the keyword `delay` if you have multiple postprocessing steps and want to define their order. If `POSTPROCESSING_DELAY` is set but the keyword `delay` is not contained in `POSTPROCESSING_STEPS`, it will be processed as last postprocessing step without being listed there. In this case, a log entry will be written on service startup to notify the admin about that situation. That log entry can be avoided by adding the keyword `delay` to `POSTPROCESSING_STEPS`. ### Custom Postprocessing Steps By using the envvar `POSTPROCESSING_STEPS`, custom postprocessing steps can be added. Any word can be used as step name but be careful not to conflict with exising keywords like `virusscan` and `delay`. In addition, if a keyword is misspelled or the corresponding service does either not exist or does not follow the necessary event communication, the postprocessing service will wait forever getting the required response to proceed and does not continue any other processing. @@ -37,8 +37,8 @@ By using the envvar `POSTPROCESSING_STEPS`, custom postprocessing steps can be a For using custom postprocessing steps you need a custom service listening to the configured event system (see `General Prerequisites`) #### Workflow -When setting a custom postprocessing step (eg. `"customstep"`) the postprocessing service will eventually sent an event during postprocessing. The event will be of type `StartPostprocessingStep` with its field `StepToStart` set to `"customstep"`. When the custom service receives this event it can savely execute its actions, postprocessing service will wait until it has finished its work. The event contains further information (filename, executing user, size, ...) and also required tokens and urls to download the file in case byte inspection is necessary. +When setting a custom postprocessing step (eg. `"customstep"`) the postprocessing service will eventually sent an event during postprocessing. The event will be of type `StartPostprocessingStep` with its field `StepToStart` set to `"customstep"`. When the custom service receives this event it can safely execute its actions, postprocessing service will wait until it has finished its work. The event contains further information (filename, executing user, size, ...) and also required tokens and urls to download the file in case byte inspection is necessary. Once the custom service has finished its work, it should sent an event of type `PostprocessingFinished` via the configured events system. This event needs to contain a `FinishedStep` field set to `"customstep"`. It also must contain the outcome of the step, which can be one of "delete" (abort postprocessing, delete the file), "abort" (abort postprocessing, keep the file) and "continue" (continue postprocessing, this is the success case). -See the [cs3 org](https://github.com/cs3org/reva/blob/edge/pkg/events/postprocessing.go) for up-to-date information of reserved step names and event definitons. +See the [cs3 org](https://github.com/cs3org/reva/blob/edge/pkg/events/postprocessing.go) for up-to-date information of reserved step names and event definitions. diff --git a/services/proxy/README.md b/services/proxy/README.md index 110d9266b..09c34ed43 100644 --- a/services/proxy/README.md +++ b/services/proxy/README.md @@ -1,6 +1,6 @@ # Proxy -The proxy service is an API-Gateway for the ownCloud Infinite Scale microservices. Every HTTP request goes through this service. Authentication, logging and other preprocessing of requests also happens here. Mechanisms like request rate limitting or intrusion prevention are **not** included in the proxy service and must be setup in front like with an external reverse proxy. +The proxy service is an API-Gateway for the ownCloud Infinite Scale microservices. Every HTTP request goes through this service. Authentication, logging and other preprocessing of requests also happens here. Mechanisms like request rate limiting or intrusion prevention are **not** included in the proxy service and must be setup in front like with an external reverse proxy. The proxy service is the only service communicating to the outside and needs therefore usual protections against DDOS, Slow Loris or other attack vectors. All other services are not exposed to the outside, but also need protective measures when it comes to distributed setups like when using container orchestration over various physical servers. @@ -102,9 +102,9 @@ The `proxy` service can use a configured store via `PROXY_STORE_TYPE`. Possible - `redis-sentinel`: Stores data in a configured redis sentinel cluster. - `etcd`: Stores data in a configured etcd cluster. - `nats-js`: Stores data using key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store) - - `noop`: Stores nothing. Useful for testing. Not recommended in productive enviroments. + - `noop`: Stores nothing. Useful for testing. Not recommended in production environments. 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 applicapable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store applies. +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 applies. 3. The proxy 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 `PROXY_OIDC_USERINFO_CACHE_NODES` in the form of `:/` like `10.10.0.200:26379/mymaster`. diff --git a/services/storage-system/README.md b/services/storage-system/README.md index 005713cfc..9bf2cc6d0 100644 --- a/services/storage-system/README.md +++ b/services/storage-system/README.md @@ -10,9 +10,9 @@ The `storage-system` service caches file metadata via the configured store in `S - `redis-sentinel`: Stores metadata in a configured Redis Sentinel cluster. - `etcd`: Stores metadata in a configured etcd cluster. - `nats-js`: Stores metadata using the key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store) - - `noop`: Stores nothing. Useful for testing. Not recommended in productive enviroments. + - `noop`: Stores nothing. Useful for testing. Not recommended in production environments. 1. Note that in-memory stores are by nature not reboot persistent. -2. Though usually not necessary, a database name can be configured for event stores if the event store supports this. Generally not applicapable for stores of type `in-memory`, `redis` and `redis-sentinel`. These settings are blank by default which means that the standard settings of the configured store applies. +2. Though usually not necessary, a database name can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`, `redis` and `redis-sentinel`. These settings are blank by default which means that the standard settings of the configured store applies. 3. The `storage-system` 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 `STORAGE_SYSTEM_CACHE_NODES` in the form of `:/` like `10.10.0.200:26379/mymaster`. diff --git a/services/storage-users/README.md b/services/storage-users/README.md index c9e1702c2..4896e210f 100644 --- a/services/storage-users/README.md +++ b/services/storage-users/README.md @@ -89,9 +89,9 @@ The `storage-users` service caches file metadata via the configured store in `ST - `redis-sentinel`: Stores metadata in a configured Redis Sentinel cluster. - `etcd`: Stores metadata in a configured etcd cluster. - `nats-js`: Stores metadata using the key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store) - - `noop`: Stores nothing. Useful for testing. Not recommended in productive enviroments. + - `noop`: Stores nothing. Useful for testing. Not recommended in production environments. 1. Note that in-memory stores are by nature not reboot persistent. -2. Though usually not necessary, a database name can be configured for event stores if the event store supports this. Generally not applicapable for stores of type `in-memory`, `redis` and `redis-sentinel`. These settings are blank by default which means that the standard settings of the configured store applies. +2. Though usually not necessary, a database name can be configured for event stores if the event store supports this. Generally not applicable for stores of type `in-memory`, `redis` and `redis-sentinel`. These settings are blank by default which means that the standard settings of the configured store applies. 3. The `storage-users` 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 `STORAGE_SYSTEM_CACHE_NODES` in the form of `:/` like `10.10.0.200:26379/mymaster`. diff --git a/services/userlog/README.md b/services/userlog/README.md index 521cadc6e..83548538a 100644 --- a/services/userlog/README.md +++ b/services/userlog/README.md @@ -15,10 +15,10 @@ The `userlog` service persists information via the configured store in `USERLOG_ - `redis-sentinel`: Stores data in a configured redis sentinel cluster. - `etcd`: Stores data in a configured etcd cluster. - `nats-js`: Stores data using key-value-store feature of [nats jetstream](https://docs.nats.io/nats-concepts/jetstream/key-value-store) - - `noop`: Stores nothing. Useful for testing. Not recommended in productive enviroments. + - `noop`: Stores nothing. Useful for testing. Not recommended in production environments. 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 applicapable for stores of type `in-memory`. These settings are blank by default which means that the standard settings of the configured store applies. +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 applies. 3. The userlog 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 `USERLOG_STORE_NODES` in the form of `:/` like `10.10.0.200:26379/mymaster`.