This way we don't need to construct the entire configuration to load a
database or database engine.
The other advantage is that it allows having options that are unique to
each database backend.
The one thing I don't like about this is `DatabaseConfig::path`, whose
existence implies all databases will have a file path, which is not
true for out-of-process databases. The only thing this is really used
for is creating the media directory. I think we should restructure the
configuration in the future to resolve this.
The previous code used `server_name` as a fallback but in reality there
is no real relationship between `server_name` and the location clients
are supposed to make requests to.
Additionally, the `insecure` option is gone, because we now allow users
to control the entire URL, so they're free to choose the scheme.
This way users can have a simpler time configuring this stuff and we can
worry about the spec compliance parts and specifying the same thing over
and over parts.
The following are now configurable:
- the OpenTelemetry endpoint,
- the tracing-flame filename, and
- whether the log output should include timestamps (useful to disable if
it goes straight into journald).
This renames:
database_backend -> database.backend
database_path -> database.path
db_cache_capacity_mb -> database.cache_capacity_mb
rocksdb_max_open_files -> database.rocksdb_max_open_files
Charles updated the NixOS module.
Co-authored-by: Charles Hall <charles@computer.surgery>
The vast majority of spans are at the info level, so increasing the log
level to info will greatly increase the amount of (useful!) inforamtion
included in the logs.
However, `ruma_state_res` generates a substantial amount of logs, so
that one gets to stay fixed at `warn` for now.
We want to be able to disable colors for complement logs (since they
are likely to be opened in a text editor). There's no pressing need for
alternative log formats, but I'm interested in whether the 'pretty'
format will be easier for debugging.
I chose to add 'log_*' options rather than making a separate 'log'
section for now. There's been some discussion about trying to separate
the tracing/logging stuff into more structured sections, but that can
happen later.
The "listening for incoming traffic on ..." log line is new, but
something I've wanted even when we only supported one listener.
I considered getting rid of `clippy::too_many_lines` by factoring out
the construction of `app` to a separate function, but found that
specifying it's type (or relevant traits) got quite hairy.
This is a config compatibility break.
The ability to listen on multiple ports, including both TLS and non-TLS,
is necessary for running complement against grapevine.
This allows the error handling to be done upfront instead of for each
use. In particular, the `toml` error now points to the span of text in
the config file where the misconfigured EnvFilter value is. This is much
better than the previous error that did not indicate what was actually
causing it to happen.
This separates concerns a bit more. We will probably want to extend the
logic for config loading in the future, and that stuff should all live
in the relevant place. This change points us in the right direction.
Just `cat` the config file. Also this code would be very annoying to
maintain. Getting rid of this also revealed that another config option
is specific to RocksDB, so `cfg`s for that have been added.
We inherited the disabled-by-default setting from conduit. Conduwuit
change it to enabled-by-default in [1]. This can make things confusing
for users migrating from conduwuit to grapevine, especially since we
currently do not log a warning when federation is disabled.
[1]: 24605e151d
This change is fully automated, except the `rustfmt.toml` changes and
a few clippy directives to allow specific functions with too many lines
because they are longer now.
This makes it possible to deploy Grapevine while using a database
originally created by Conduit, including leaving the admin bot user's
localpart the same as before.
