Config overhaul: change env var names convention

[josecelano]

Parent issue: #401
Depends on: #850
Relates to:

• Rename tracker env vars torrust-index#576
• Rename tracker env vars torrust-index-gui#555

After migrating to Figment, we have started using new conventions for configuration env vars:

For example:

• The old var name: TORRUST_TRACKER_API_ADMIN_TOKEN
• The new name: TORRUST_TRACKER__HTTP_API__ACCESS_TOKENS__ADMIN

That change was introduced because Figment needs a separator for the different levels. The default one is a dot (.) but it does not work as a Bash var name. see SergioBenitez/Figment#103

Subtasks

• Rename vars in the Tracker
• Rename vars in the Index
  Rename vars in the Index GUI

[josecelano]

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

1. 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 to TORRUST_TRACKER__CONFIG, we will not be able to add a new config option in the toml file.

2. 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?

[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.

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... :)

[josecelano]

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 and TORRUST_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.