Comments (3)
Hi @da2ce7,
There are at least two different types of env vars:
En vars that are configuration options:
TORRUST_TRACKER_API_ADMIN_TOKEN -> TORRUST_TRACKER__HTTP_API__ACCESS_TOKENS__ADMIN
For the time being, we are only overwriting one, although it's possible now to overwrite all of them, by following Figment
convention for the name.
Other env vars are used the container and configuration initialization:
TORRUST_TRACKER_CONFIG -> TORRUST_TRACKER__CONFIG
TORRUST_TRACKER_PATH_CONFIG -> TORRUST_TRACKER__PATH_CONFIG
TORRUST_TRACKER_DATABASE_DRIVER -> TORRUST_TRACKER__DATABASE_DRIVER
Questions
-
Should we use a different prefix for env vars than represent config options? or the same prefix for all env vars? If we use the same prefix we cannot introduce config options in the future with a name that is already used. For example, if we rename
TORRUST_TRACKER_CONFIG
toTORRUST_TRACKER__CONFIG
, we will not be able to add a newconfig
option in the toml file. -
There are two env vars representing the same thing.
- TORRUST_TRACKER_DATABASE_DRIVER:
sqlite3
,mysql
. - TORRUST_TRACKER__DB_DRIVER:
Sqlite3
,MySQL
.
The first one is used in the container (DB initialization) and the second one is used internally to load the right SQLx driver. We have not used it, but now with Figment it would be possible to use it.
My proposal
I would use different prefixes for the different types of env vars:
# Config options. Prefix `TORRUST_TRACKER_CONFIG_OPTION_`
# Overwrite one option:
TORRUST_TRACKER_CONFIG_OPTION_HTTP_API__ACCESS_TOKENS__ADMIN
# Others env vars.
# Provide the config in a toml format (now with Figment it does need to be a complete configuration). It replaces the current `TORRUST_TRACKER_CONFIG` env var.
TORRUST_TRACKER_CONFIG_TOML="***"
# Provide the filepath for a toml file. It replaces the current `TORRUST_TRACKER_PATH_CONFIG`
TORRUST_TRACKER_CONFIG_TOML_PATH="./**/**/tracker.toml"
# Overwrite DB driver config option in toml file:
TORRUST_TRACKER_CONFIG_OPTION__DB_DRIVER=Sqlite3
# Remove the current env var used in the container config and use the same we use in the config file. That would not allow the user to setup the container with one DB driver but run the application with a different one. But I guess that a desiderable effect.
#TORRUST_TRACKER_DATABASE_DRIVER
With this approach, the double underscore would be used only for namespaces in the parsed configuration from toml files (or json files). And there will not be conflicts between "global" env vars and "toml config options". It would also be easier to identify config options by the even var name.
What do you think @da2ce7?
from torrust-tracker.
@josecelano good and logical proposal, I like it.
The only question is how do we separate it if somebody has more than one instance of a service.
The namespace for the TORRUST_TRACKER_CONFIG_TOML
and TORRUST_TRACKER_CONFIG_TOML_PATH
sound good.
Then TORRUST_TRACKER_CONFIG_OPTION__DB_DRIVER
is clear that it is a value within the config... good to move to this standard naming from: TORRUST_TRACKER_DATABASE_DRIVER
.
The only other option would be replace _CONFIG_OPTION
with _CONFIG_OVERRIDE
, since we are pulling in the default options anyway... :)
from torrust-tracker.
Hi @da2ce7,
@josecelano good and logical proposal, I like it.
The only question is how do we separate it if somebody has more than one instance of a service.
I think there is no way to overwrite a single item in an array or a single field in a dictionary. If I'm not wrong you have to overwrite the whole Figment value.
See: https://docs.rs/figment/latest/figment/providers/struct.Env.html
But I'm going to merge a PR that defines defaults values in serde, so you don't need to provide a full item in the array of dictionary. For example, the following code:
TORRUST_TRACKER__HTTP_TRACKERS=[{enabled=true}] cargo run
will create a new HTTP Tracker configuration, which is enabled (default value is disabled), and the rest of the fields are the default values. But you can provide all fields if you want. Another example:
TORRUST_TRACKER__HTTP_TRACKERS="[{enabled=true, bind_address=0.0.0.0:7070}, {enabled=true, bind_address=0.0.0.0:7071}]" cargo run
That produces:
http_trackers: [
HttpTracker {
enabled: true,
bind_address: 0.0.0.0:7070,
ssl_enabled: false,
tsl_config: TslConfig {
ssl_cert_path: Some(
"",
),
ssl_key_path: Some(
"",
),
},
},
HttpTracker {
enabled: true,
bind_address: 0.0.0.0:7071,
ssl_enabled: false,
tsl_config: TslConfig {
ssl_cert_path: Some(
"",
),
ssl_key_path: Some(
"",
),
},
},
],
The namespace for the
TORRUST_TRACKER_CONFIG_TOML
andTORRUST_TRACKER_CONFIG_TOML_PATH
sound good.
The idea is to be able to add TORRUST_TRACKER_CONFIG_JSON
and TORRUST_TRACKER_CONFIG_JSON_PATH
, etcetera.
Then
TORRUST_TRACKER_CONFIG_OPTION__DB_DRIVER
is clear that it is a value within the config... good to move to this standard naming from:TORRUST_TRACKER_DATABASE_DRIVER
.
OK.
The only other option would be replace
_CONFIG_OPTION
with_CONFIG_OVERRIDE
, since we are pulling in the default options anyway... :)
I like it. It's more explicit. My only concern is if, in the future, we could make that also customizable. A flag like --ignore-defaults
or something like that. But I don't see any reason to do that now.
from torrust-tracker.
Related Issues (20)
- Error building the tracker: `unresolved import std::hash::DefaultHasher` HOT 1
- Config overhaul: version 2 for the configuration toml file (breaking changes) HOT 4
- Move from `log` to `tracing` crate
- New config option for logging style
- Enable colour in console output HOT 2
- Docker build is failing: `failed to load bitcode of module "criterion-af9a3f7183f1573d.criterion.b69900c842eb33fa-cgu.08.rcgu.o"`
- Running unit test in coverage workflow is failing HOT 3
- Add a workflow to run a basic benchmark for the UDP tracker
- Remove log output from UDP tracker client
- UDP server: alternative implementation to avoid aborting too many requests HOT 1
- Config overhaul: split tracker mode
- Fix docker warning in `Containerfile`
- Config overhaul: improve admin experience
- Config overhaul: rename `log_level` to `threshold`
- Config overhaul: add version and namespace to the configuration HOT 2
- Config overhaul: make some fields mandatory (remove default value) HOT 1
- Config overhaul: define current config version as version 2
- Config overhaul: remove secrets when final config is printed to console
- Config overhaul: lowercase for `DatabaseDriver` HOT 1
- Config overhaul: use an explicit section for metadata HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from torrust-tracker.