-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Str 786 main refactor part1 #561
Conversation
61486b8
to
95d94a5
Compare
0b95080
to
c555431
Compare
bin/strata-client/src/args.rs
Outdated
pub fn derive_config(&self) -> Result<Config, String> { | ||
let args = self.clone(); | ||
Ok(Config { | ||
bitcoind_rpc: BitcoindConfig { | ||
rpc_url: args | ||
.bitcoind_host | ||
.ok_or_else(|| "args: no bitcoin --rpc-url provided".to_string())?, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would make this a toplevel function or even like from_args
on Config
, it doesn't really make sense to be a member function on Args
. This also makes some sense to use anyhow
instead of manipulating string error messages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea behind this was that Args seems to be more inside the bin whereas Config seems somewhere common which other crates can/do use. To me, it doesn't make sense to pull in Arg dependency where config is defined.
I think config should not be in bin. It is just being used everywhere so it makes sense to keep it somewhere common and it should not have dependency on Args.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're separating the actual service config from the inner client/node config internally then yeah moving it apart makes sense.
But how these fns are organized here does feel weird to me.
pub fn update_config(&self, config: &mut Config) { | ||
let args = self.clone(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, doesn't make sense to be a member function on Args
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same reasoning as above.
bin/strata-client/src/args.rs
Outdated
rpc_url: args.reth_authrpc.unwrap_or("".to_string()), // TODO: sensible default | ||
secret: args.reth_jwtsecret.unwrap_or_default(), /* TODO: probably | ||
* secret should be | ||
* Option */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no sensible default here and we always need a secret. We're not at the point where we can run without reth, so make these required.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh these, I haven't had a change to go through in detail. These were just being moved around. Will make it required.
pub type CommonDb = | ||
CommonDatabase<L1Db, L2Db, SyncEventDb, ClientStateDb, ChainstateDb, RBCheckpointDB>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to get rid of this CommonDatabase
abstraction since it's not useful anymore. But since there's a lot of stuff still using the Database
trait I'm not sure how feasible that is yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The feasibility is yet to be assessed. Once things are in place where they should be, we can then get rid of the stuffs.
crates/common/src/config.rs
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This crate is for things that are common to every possible service, like logging. This configuration is specific to the strata client. Do you think it makes sense move it to a new node
crate like Reth has and shift more init logic there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think that would be better. I've mentioned the rationale behind this in one of the comments above.
I am also working on a new crate, in a different branch, which I've named as "client". But I do like the name "node" more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So yeah, let's keep Config
under common
as it is fairly serves its purpose(being "common" to almost all other crates in some ways). Can move to node crate in the subsequent PRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No it doesn't serve its purpose. That's just not what the crate is intended for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The term "common" refers to what's shared underlying infra between all of the binaries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not a consensus-related type like what the primitives crate is for.
Yes as I said before it would make sense to have a new node crate like Reth has.
because reader, writer, bridge, etc have their configs derived from this Config.
But we don't want to make btcio dependent on this new node crate, the node crate makes sense to be dependent on btcio instead. The btcio services have their own configuration that we build from our config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we have a new crate config
? Well, do you agree that Config
should be somewhere outside of bin?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It just makes sense in that node crate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thought some more and decided to have a new config
crate. This way, crates depending on config
don't have to pull in the node
crate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would be depending on this config crate but not the node crate?
c555431
to
c870a11
Compare
dcab80f
to
76a8c03
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I think I'm fine with this as-is. It's still a work in progress but this is an improvement.
Description
This is the part 1 of main refactor which moves around a couple of things:
Config
tocrates/config
as it is where it should be. Corresponding minor changes toReaderConfig
andArgs
methods.NodeStorage
, which at the moment consolidates two managers. It will get extended and included in the context in future.Handle
fromTaskManager
and use it instead of passing aroundruntime
everywhere.Type of Change
Notes to Reviewers
This is a part of bigger refactor that lies ahead and I kindly request to review this as soon as possible.
Checklist
Related Issues