refactor: Split configs in server and service - #671
Conversation
We used to use the same config for the service and server (aka the binary). This is confusing when creating configs to use with e.g. iroh-one, iroh-embed or iroh-share because some fields are not used. This splits off the config structs to avoid this problem, services now have a Config and binaries a ServerConfig. This allows creating the services standalone without all the baggage a server needs. While this isn't many fields yet, this will get worse as we add more features (this is split off from another PR where this seemed useful).
| // TODO: I'd prefer to include [`Config`] under the `store` field like iroh-one does. But | ||
| // that's a backwards incompatible change. |
There was a problem hiding this comment.
@Arqu I guess you're the main person that uses these config files? What are your thoughts here?
There was a problem hiding this comment.
For the p2p and gateway services this duplication is painful, it would be a lot nicer if we could break backwards compatibility of the config file formats.
There was a problem hiding this comment.
You should break it, there's no real dependency on them yet. Better break them now than later.
| path: db_path.to_path_buf(), | ||
| rpc_client: rpc_store_client_config, | ||
| metrics: iroh_metrics::config::Config { | ||
| tracing: false, // disable tracing by default |
There was a problem hiding this comment.
This is proof that the current state of things is weird. This did nothing IIUC.
| /// This is the configuration which the gateway server binary needs to run. This is a | ||
| /// superset from the configuration needed by the gateway service, which can also run | ||
| /// integrated into another binary like iroh-one, iroh-share or iroh-embed. | ||
| // TODO: I'd prefer to include [`Config`] under the `gateway` field liek iroh-one does. But |
There was a problem hiding this comment.
I think this should be done before merging, to avoid the duplication, don’t be afraid to break apis
There was a problem hiding this comment.
Yeah, feel free to break this, there's nobody really depending on it yet.
Arqu
left a comment
There was a problem hiding this comment.
From a prue code perspective this is 👍
However this "works" for the metrics piece more by coincidence than design at this point.
The reason each had their own metrics directly planted was that different services used to run a different feature set of the metrics crate, which would initialize the metrics just for that service.
This kinda nukes that notion completely. But it was not doing that anyways since the Cargo.toml refactors because it's now from a global workspace and I believe it just builds all the features regardless.
Functionally this is fine, it just wastes a little bit more resources on the metrics side. Not a ton though. I'll spend some time thinking about this.
| /// This is the configuration which the gateway server binary needs to run. This is a | ||
| /// superset from the configuration needed by the gateway service, which can also run | ||
| /// integrated into another binary like iroh-one, iroh-share or iroh-embed. | ||
| // TODO: I'd prefer to include [`Config`] under the `gateway` field liek iroh-one does. But |
There was a problem hiding this comment.
Yeah, feel free to break this, there's nobody really depending on it yet.
| // TODO: I'd prefer to include [`Config`] under the `store` field like iroh-one does. But | ||
| // that's a backwards incompatible change. |
There was a problem hiding this comment.
You should break it, there's no real dependency on them yet. Better break them now than later.
Hum, this should not be the case. If you look at
|
This adds a StoreConfig section to remove duplication.
lets remove that struct from the other places too
|
After taking the wrong approach to resolve the TODOs and going astray for a while I've now tiedied this up. So the PTAL |
We used to use the same config for the service and server (aka the binary). This is confusing when creating configs to use with e.g. iroh-one, iroh-embed or iroh-share because some fields are not used.
This splits off the config structs to avoid this problem, services now have a Config and binaries a ServerConfig. This allows creating the services standalone without all the baggage a server needs.
While this isn't many fields yet, this will get worse as we add more features (this is split off from another PR where this seemed useful).
Todo