Enable using values from environment variables from tahoe.cfg #2833
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#2833
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
Tagging and linking
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.