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
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
The text was updated successfully, but these errors were encountered:
Describe the bug
Currently, we mostly parse config in config.go, but keep the
deployment
,application.features
, andapplication.logLevel
keys separate. While thedeployment
key makes sense in that it pertains only to resources deployed via Helm and as such never really reaches the Connaisseur application, theapplication
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
The text was updated successfully, but these errors were encountered: