-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use figment
for configuration
#808
Use figment
for configuration
#808
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #808 +/- ##
===========================================
- Coverage 78.78% 78.76% -0.02%
===========================================
Files 163 168 +5
Lines 9252 9291 +39
===========================================
+ Hits 7289 7318 +29
- Misses 1963 1973 +10 ☔ View full report in Codecov by Sentry. |
d925a3c
to
16b0486
Compare
16b0486
to
a8b4624
Compare
ad54bdf
to
7eb469a
Compare
With Figment, you can overwrite all config options using env vars. I have enabled that feature. You only have to do this: let figment = Figment::new()
.merge(Toml::file("Config.toml"))
.merge(Env::prefixed("TORRUST_TRACKER_")); We were overwriting only one value: # Please override the admin token setting the
# `TORRUST_TRACKER_API_ADMIN_TOKEN`
# environmental variable!
[http_api.access_tokens]
admin = "MyAccessToken" With the env var |
It will replace the custom code for configuration inyection.
- Clone config strcuctures into a new mod `v1`. - Introduce versioning for configuration API. - Split config sections into submodules. TODO: - Still using root mod types in production. - Not using figment to build config in production.
- Clone config strcuctures into a new mod `v1`. - Introduce versioning for configuration API. - Split config sections into submodules. TODO: - Still using root mod types in production. - Not using figment to build config in production.
This is part of the migration to Figment in the configuration. This expose new versioned types (version 1). However, those types still used the old Config crate. Replacement by Figment has not been done yet.
This replaces the crate `config` with `figment` in the Configuration implementation.
It was replaced by `figment`.
Enable Figment ability to overwrite all config options with env vars. We are currently overwriting only this value: ```toml [http_api.access_tokens] admin = "MyAccessToken" ``` With the env var `TORRUST_TRACKER_API_ADMIN_TOKEN`. The name we gave to the env var does nto follow Figment convention which is `TORRUST_TRACKER_HTTP_API.ACCESS_TOKENS.ADMIN`. We have to keep both options until we remove the old one in the rest of the code.
2bb7f6d
to
146b77d
Compare
For example, the env var `TORRUST_TRACKER__HTTP_API__ACCESS_TOKENS__ADMIN` would be the config option: ``` [http_api.access_tokens] admin = "MyAccessToken" ``` It uses `__` double underscore becuase dots are not allowed in Bash names. See: https://www.gnu.org/software/bash/manual/bash.html#Definitions ``` name A word consisting solely of letters, numbers, and underscores, and beginning with a letter or underscore. Names are used as shell variable and function names. Also referred to as an identifier. ```
In the end, you can customize the separator in Figment. I'm using a double underscore to generate a valid Bash name:
@da2ce7, any other preference for the separator? If we want to generate a valid Bash name we don't have other options. https://www.gnu.org/software/bash/manual/bash.html#Definitions |
Until it's updated in this repor and the Index repo you can overwrite the admin token using the new env var name and the old one (deprecated): - New: `TORRUST_TRACKER__HTTP_API__ACCESS_TOKENS__ADMIN` - Old (deprecated): `TORRUST_TRACKER_API_ADMIN_TOKEN` THe new one uses exactly the strcuture and atribute names in the toml file, using `__` as the separator for levels. We can remove the test when we remove the deprecated name.
Now, you are able to run the tracler like this: ``` TORRUST_TRACKER_CONFIG="" cargo run ``` Default values will be used for the missing values in the provided configuration. In that case, none of the values have been provided, so it will use default values for all options.
ACK 0252f30 |
Finally, I decided to merge this PR at this point with:
I have updated the Overhaul Configuration issue by adding the next steps. |
@josecelano I think that the double-underscore is the natural choice :) |
Hi @da2ce7, I've extended the question from only "which separator to use" (it seems |
Relates to: #790
This PR migrates the configuration implementation to use Figment as suggested by @da2ce7 here.
Context
I was working on a configuration validation in this PR. I wanted to validate things like socket addresses earlier when we parse the configuration instead of waiting until the app launches the service. For example, the UDP tracker configuration contains the
bind_address
:That configuration maps to a
String
:I realized that kind of very basic validation could be actually done just changing the types in the configuration. For example:
There are other functionalities like overwritting values in the config file with env vars that can be implemented with Figment (merge).
So I decided to migrate to Figment the current version and update the configuration after the migration.
Subtasks without changing current config API (toml or struct)
Default
trait for config sections (not only root config).FUTURE PR: Subtasks changing current config API (structs)
These changes do not change the toml file configuration, only the parsed type.
FUTURE PR: Subtasks changing current config API (toml and structs)
At this point, an extra validation could be needed like the one described here. For example, if you enable TSL for the tracker API you must provide both the certificate path and the certificate key path:
I think that type of validation could be implementented after parsing the inyected config or maybe just reorganizcing the toml file structure. For example:
No API enabled:
# No section [http_api]
API enabled but no TSL enabled:
API enabled with TSL enabled:
We would not need the
enabled
field. If the section is present the feature is enabled. If it's not it means that feature is disabled.These breaking changes will be added in a new
v2
configuration in a new PR.