Layered Dynamic Configuration

[kevsmith]

Overview

Relay and Cog currently provide per-bundle dynamic configuration. These config values are derived from a yaml file stored in a directory named after the related bundle. The file is re-read on each pipeline execution which allows for nearly instantaneous configuration changes.

The design presents a flattened configuration where all commands from the same bundle share the same config regardless of the invoking user or invocation location. It is sufficient for simple use cases but quickly becomes limited when you attempt to customize the configuration based on runtime attributes such as room or invoking user.

Design Overview

We can support per-room and per-user customization by extending dynamic configuration to include the notion of room- and user-specific "layers". Configuration layers overlay the base dynamic configuration based on who invoked a command and where the invocation occurred. Layers are applied using a small set of rules making them both deterministic and easy to understand.

Layers

Layers will be modeled as subdirectories inside a bundle's dynamic configuration directory. Room layer directories will be prefixed with room_. The room layer for DMs will be the special name room_direct. User layer directories will be prefixed with user_. For example, mist's dynamic configuration would look like the below diagram if it included both user and room layers.

$RELAY_DYNAMIC_CONFIG_ROOT
   |
   |--- mist
         |
         |--- config.yaml
         |--- room_ops
         |        |
         |        |--- creds.yaml
         |        |--- tokens.yaml
         |--- user_susan
                  |
                  |--- creds.yaml

Layer Composition Rules

1. Layers are evaluated in least-to-most specific order.
   1. Base context (config.yaml, if it exists)
   2. Room
   3. User
2. Each subsequent layer can overwrite the contents of prior layers in the event of a conflict. In other words, room layer configuration overrides the starting named context and user layer overrides both.
3. Merging two layers together is a shallow merge of top-level keys only.
4. Layers are selected by exact case-insensitive string match. Room and user names are downcased before evaluating matches.
   1. room_ops matches a command invocation from rooms named "Ops", "ops", and "OPS".
   2. user_susan matches a command invocation from users named "susan", and "Susan".
5. The base layer is restricted to a single file named config.yaml for backwards compatibility and future extensibility.
6. Files in the room and user layers are processed by name sorted in lexicographical ascending order.

[christophermaier]

We decided to modify the original plan a bit and now only allow for a single room / user file per bundle. The directory tree will now look like this:

$RELAY_DYNAMIC_CONFIG_ROOT
   |
   |--- mist
         |
         |--- config.yaml
         |--- room_ops.yaml
         |--- room_general.yaml
         |--- user_susan.yaml
         |--- user_bob.yaml