Describe the bug
Currently, we mostly parse config in config.go, but keep the deployment, application.features, and application.logLevel keys separate. While the deployment key makes sense in that it pertains only to resources deployed via Helm and as such never really reaches the Connaisseur application, the application keys stands out as something that is passed to Connaisseur via env vars and is handled by feature.go and logging.go.
I think this is a remnant of the way we handled it in Python (read: is technical debt) and there's no reason to pass parts of the application config via the environment.
Expected behavior
As a developer with a config object, I have all the config I need, i.e. I don't need to handle two different ways of changing config options if I want to change something
Describe the bug
Currently, we mostly parse config in config.go, but keep the
deployment,application.features, andapplication.logLevelkeys separate. While thedeploymentkey makes sense in that it pertains only to resources deployed via Helm and as such never really reaches the Connaisseur application, theapplicationkeys stands out as something that is passed to Connaisseur via env vars and is handled by feature.go and logging.go.I think this is a remnant of the way we handled it in Python (read: is technical debt) and there's no reason to pass parts of the application config via the environment.
Expected behavior
As a developer with a config object, I have all the config I need, i.e. I don't need to handle two different ways of changing config options if I want to change something