As of today, most of Tuleap code still rely on some files to be written on the file system for the configuration (like /etc/tuleap/conf/local.inc)
It served us well but is no far from ideal in a Cloud/Container world where modifying the content of an image is not a good practice (in addition to a PITA).
Prior to this there is some clean-up needed:
- all non PHP code (python & perl wrappers mainly) must be updated to exec
tuleap config-get instead of trying to parse local.inc
- usage of
PluginFileInfo to gather variables defined for a plugin should be moved to ForgeConfig
Get
The goal is to be able to configure/override all Tuleap variables in a flexible manner. The proposal is to introduce a precedence for variable fetching:
- Database
- $file.inc
- Environment Variable
- $file.inc.dist (or code based default, see below)
With this approach we can keep the goo'old $file.inc for existing installation while going /etc/tuleap less in containers.
The proposal for Environment Variables is to prefix all of them with TULEAP_ (eg TULEAP_SYS_DEFAULT_DOMAIN would override $sys_default_domain set in local.inc). If the environment variable starts with TULEAP_FILE_XXX then the value is assumed to be read from a file (eg. TULEAP_FILE_SYS_DBPASSWD would set the value of $sys_dbpasswd with the content of the file).
A special case should be taken into account for the DB password secret (because it can be provided by ENV or by file.inc but not by DB).
WARNING: we also need to take into account the existing code that relies on /etc/tuleap/conf/local.inc to be present to decide if Tuleap was already installed or not (e.g. startup sequence of containers).
Management of configuration keys
The loading of values should no longer depends on $file.inc.dist:
- All configuration keys should be transferred to source code with constants.
- Whenever possible, the keys are associated to classes that are related to the variable
- New attribute is added to defined the default value (existing default values in DB should be removed from
database_initvalues.sql but existing platforms with values already set won't be "purged").
- New attribute to distinguish configuration keys that old secrets.
- secrets will be stored encrypted in DB
- secrets won't be leaked with tools to get all variables (eg
tuleap config-get --all to be added)
Special case of secrets not associated to variables
There are 2 secrets ATM that are not in a variable:
-
/etc/tuleap/conf/encryption_secret.key
- Can be provided as ENV or ENV_FILES, otherwise it's generated on the fly
-
/etc/tuleap/plugins/prometheus_metrics/etc/metrics_secret.key
- Introduce a new configuration key for this so it can be managed like other secrets (ENV/ENV_FILE or encrypted in DB)
Set
When the new GET sequence is in place, the change of variables must also be updated.
The proposal is to allow tuleap config-set to write any variables in the database.
This approach combined to the new GET sequence would allow to manipulate all variables with "config-set" (as of today it's limited to variables that are "database native").
It's, again, far from ideal to mandate an SSH connection to a running environment to change a variable. So, in addition to the storage modification, a new REST route to manipulate the variables is introduced (definition to be precised).