Configuration rework - let me know what you think

[gabehf]

The Problem

Currently, all configuration is done from environment variables. This means that any time you want to make changes to your configuration, you have to enter whatever environment you use to manage your containers, change the variable, and redeploy the container. For me, this is too cumbersome, and in my opinion this is too much effort for many configuration options.

The Proposal

The idea is to separate the current configuration options into three parts:

1. Options that should stay as environment variables (e.g. bind address, listen port, etc.)
2. Options that should be configurable via UI (e.g. LastFM key, subsonic login, relay configuration, etc.)
3. Options that should not be removed from config (e.g. time gates for import, image downloading during import, etc.)

Basically, I want to separate deployment configuration for application configuration, where the former is done via environment variables, and the latter through the UI.

I would also want to look into backing the application configuration that is managed via the UI to a toml/yaml/whatever file, so that config can be moved easily to a new instance or machine. This could also negate the need to save configuration to the database at all, but I imaging keeping the running configuration state and the file state consistent could be more challenging than it seems, although that's just speculation since I haven't written a system like this before.

Why I'm looking for input

I'd like to know if anyone has strong feelings about how application config should be managed. I've already made my decision that much of the application state will be managed in-UI, so I'd like some perspectives on what people would like to see, considerations about migrating current config to the new system, etc.

[flyingcakes85]

Options that should be configurable via UI (e.g. LastFM key, subsonic login, relay configuration, etc.)

Do you plan to allow configuring them via env vars if the user wants to? My approach would be to allow configuring via env vars, but override them if user changes it in UI settings. That could be messy though.

But if you're able to put those config in a TOML/YAML file as you mentioned, we could skip the need for env vars. As long as the config is editable through vim in my VPS shell, its perfect.

[doasu]

FWIW, I'd prefer it if all options were in some way configurable declaratively, be it via envvars or config files.

Makes it easier to set up instances for testing as well as serve Koito on systems without persistence.