You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Options that should stay as environment variables (e.g. bind address, listen port, etc.)
Options that should be configurable via UI (e.g. LastFM key, subsonic login, relay configuration, etc.)
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.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
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:
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.
Beta Was this translation helpful? Give feedback.
All reactions