tahoe-lafs/trac-2024-07-25

Enable using values from environment variables from tahoe.cfg #2833

New issue

Closed

opened 2016-09-25 17:02:48 +00:00 by amontero · 2 comments

amontero commented

2016-09-25 17:02:48 +00:00

Owner

Also, Docker itself makes heavy use of env vars for host IPs and ports when linking containers.

Some kind of placeholder or token syntax instead of literal values, such as %VARNAME or {VARNAME} could be added to declare a value which would be env var replaced. The icing on the cake would be Bash syntax, which allows defaults ${VARNAME:-default_value}.

This would make Tahoe-LAFS a lot more dynamically configurable and more Docker-friendly, since env vars are commonplace.

Related ticket: #1401

As I progress through dockerizing my setup, I've noticed that being able to use values from environment vars would make Tahoe-LAFS more easily configurable. It would be beneficial to use arbitrary env var values to replace any configuration option value from inside tahoe.cfg (perhaps also other files, to deal with secrets, too). Also, Docker itself makes heavy use of env vars for host IPs and ports when linking containers. Some kind of placeholder or token syntax instead of literal values, such as %VARNAME or {VARNAME} could be added to declare a value which would be env var replaced. The icing on the cake would be Bash syntax, which allows defaults ${VARNAME:-default_value}. This would make Tahoe-LAFS a lot more dynamically configurable and more Docker-friendly, since env vars are commonplace. Related ticket: #1401

tahoe-lafs added the

labels 2016-09-25 17:02:48 +00:00

tahoe-lafs added this to the undecided milestone 2016-09-25 17:02:48 +00:00

amontero commented

2016-09-25 17:06:39 +00:00

Author

Owner

Tagging and linking

exarkun commented

2020-01-21 20:16:24 +00:00

Author

Owner

A node configuration is a pretty complex structure. Representing it completely in environment variables seems likely to me to be something of a mess.

There are also parts of the configuration which are sensitive and should be kept secret and environment variables are not a way to accomplish that.

I'd suggest that for things like Docker images, the image itself should be somewhat tailored to a specific use and should accept some configuration in environment variables - then turn around and write a tahoe.cfg and start up a node pointed at that.

That is, the Tahoe node process itself should not directly support any configuration as environment variables.

An alternative to this would be for Tahoe to expose an API that allows full control over configuration. Then, a bare-bones node could be started up and then configured with API calls containing arbitrary configuration.

A node configuration is a pretty complex structure. Representing it completely in environment variables seems likely to me to be something of a mess. There are also parts of the configuration which are sensitive and should be kept secret and environment variables are not a way to accomplish that. I'd suggest that for things like Docker images, the image itself should be somewhat tailored to a specific use and should accept *some* configuration in environment variables - then turn around and write a tahoe.cfg and start up a node pointed at that. That is, the Tahoe node process itself should not directly support any configuration as environment variables. An alternative to this would be for Tahoe to expose an API that allows full control over configuration. Then, a bare-bones node could be started up and then configured with API calls containing arbitrary configuration.

tahoe-lafs added the

wontfix

label 2020-01-21 20:16:24 +00:00

exarkun closed this issue

2020-01-21 20:16:24 +00:00