devchat notes 05-Sep-2017

Brian Warner warner at lothar.com
Thu Sep 21 07:18:34 UTC 2017


On 9/19/17 12:59 AM, Lukas Pirl wrote:
>
> On 09/19/2017 07:39 AM, Brian Warner wrote as excerpted:
>> * switching config from (tahoe.cfg, yaml files) to single sqlite DB
>
> What is the motivation behind this? As a (small-scale, part-time)
> sysadmin, this sounds not too attractive to me. Most of *NIX tools
> survived the last decades with plain text config files quite well, no?

That's a good question. I'm not yet sold on it, but the basic idea is
that we've got three basic categories of node state, and it might be
nice to manage them all in the same way:

1: human-edited configuration settings (e.g. introducer.furl)
2: machine-edited configuration (e.g. magic-folders config)
3: machine-managed persistent state (e.g. introducer_cache.yaml)

We currently edit #1 (tahoe.cfg) with a text editor, using a
human-friendly machine-parseable format (the .INI format). #2 is written
into tahoe.cfg by some CLI commands. #3 is written in YAML format each
time we hear something new from the introducer, but it can be copied
into "servers.yaml" by the user if they want to override the set of
servers that we'll use.

Having machines edit tahoe.cfg is dangerous, because we never know when
a human might be editing it at the same time: one of them might
overwrite the other's changes. The running node also doesn't notice when
the config is changed, so you have to reboot your node for any of those
changes to take effect.

But it'd be nice if the running node could modify that config, so you
could do something like a web-based node configuration tool. Lots of
other projects have no config file to edit, you just start them and then
a web page opens up, and you do all your other configuration through
that page. If the running node could safely modify its stored
configuration, we could build something like this.

The arguable benefit of using a proper database for everything would be
that changes would be atomic, and there'd be a schema enforced on
everything. I thought I remembered Glyph making this argument a while
back, but I wasn't able to find it on his blog just now
(https://glyph.twistedmatrix.com/archives.html). But I *did* find some
arguments by the SQLite team that application document save-data file
formats (think .doc or .xls) should really be single-file sqlite
databases[1], and I think they apply here too.

The down-side, of course, is that we have to provide CLI tools to modify
the config files (and/or that web-based configurator). On the third
hand, a dedicated "tahoe config" subcommand could use a socket to notify
the running node that something had changed, maybe avoiding the need to
reboot the node each time.

I like the simplicity of our tahoe.cfg file, so I'm not really pushing
hard for replacing it. But it *would* be awfully nice if it were
possible to have the node edit it safely. Maybe we just need a lock
around the file, and have a "tahoe edit-config" command that grabs the
lock before spawning your favorite editor.

cheers,
 -Brian

[1]: https://sqlite.org/appfileformat.html




More information about the tahoe-dev mailing list