-
Notifications
You must be signed in to change notification settings - Fork 57
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
chore: discv5 re-org setup #1815
Conversation
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.
Thanks for the PR! However, I see that are a few points that I'd adapt a bit more, IMHO.
I hope that helps :)
apps/wakunode2/app.nim
Outdated
@@ -94,8 +97,137 @@ func version*(app: App): string = | |||
|
|||
## Initialisation | |||
|
|||
proc networkConfiguration(conf: WakuNodeConf): NetConfigResult = |
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 think is better to have these two WakuNodeConf
-procs in https://github.com/waku-org/nwaku/blob/master/apps/wakunode2/config.nim
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.
True
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.
Not entirely sure I agree. These procs are concerned with translating the already-initialised config to interpreted config types that are specific to the app. In contrast, config.nim
is only interested in parsing and initialising external config and is already complex enough as is without more app constructs. I'd be happy if we move these two functions to a new network_config.nim
module to keep app.nim
cleaner, but happy to go with majority opinion here. :)
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.
Lets rename config.nim
to ext-config.nim
then? or user-config.nim
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.
Actually, the best place I think is the next file, where the NetConfig
is declared:
https://github.com/waku-org/nwaku/blob/master/waku/v2/node/config.nim
apps/wakunode2/app.nim
Outdated
rng: ref HmacDrbgContext | ||
nodeKey: crypto.PrivateKey |
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.
IMO, the App shouldn't know anything about nodekey
. I believe we need to keep the App as simple and generic as possible. The only one interested in the nodekey
is the node
instance, which is already part of the App.
The same applies to netConf
. Both the nodeKey
and netConf
are derived/created from the information in conf
. And I think it should be the WakuNodeConf
(config.nim module) the one in charge of translating the information from the outer world (the user params) into the wakunode space.
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 agree with the principle but both discv5
and node
require keys for setup that why it's higher in the call chain.
Would calling it appkey
helps :P
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.
We indeed have an appKey
if it's used to setup both the discovery and the node. The appKey
is then used to initialise the (logically distinct) keys for the node and discv5 with the same value.
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 understood :)
However, given that discv5
should act as a separate service, a good place to start it would be in the next proc:
Line 763 in a44d4bf
proc setupMonitoringAndExternalInterfaces*(app: var App): AppResult[void] = |
The key could be generated there from the 'key' info in the config.
apps/wakunode2/app.nim
Outdated
@@ -467,7 +531,7 @@ proc initNode(conf: WakuNodeConf, | |||
|
|||
proc setupWakuNode*(app: var App): AppResult[void] = | |||
## Waku node | |||
let initNodeRes = initNode(app.conf, app.rng, app.peerStore, app.dynamicBootstrapNodes) | |||
let initNodeRes = initNode(app.conf, app.netConf, app.rng, app.nodeKey, app.record, app.peerStore, app.dynamicBootstrapNodes) |
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 comment doesn't add nothing new from what I already mentioned :)
However, I believe we could generate the netConf
, nodeKey
and record
inside the initNode
with the information provided by the app.conf
param.
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 can't do that because discv5 will not be in initNode
but in setupWakuNode
<- could be renamed to Waku app?
BTW the term app and node are not super defined IMO. The binary is a Waku node but internally it's called app and has a node inside it's confusing.
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.
Okay got it! What if we try to do something similar that is done with the rest server?
I mean, start the discv5
service in
Line 772 in a44d4bf
let startRestServerRes = startRestServer(app, app.conf.restAddress, Port(app.conf.restPort + app.conf.portsShift), app.conf) |
I don't have strong opinion about renaming the setupWakuNode
. Both cases can be correct :)
For more context check out d19d192 |
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.
Generally happy with this direction. Agree that we can start clarifying terms between "app" and "node" (e.g. appKey
). I know this is WIP to prepare for next step in refactoring, so feel free to address suggestions in this or next PR.
apps/wakunode2/app.nim
Outdated
rng: ref HmacDrbgContext | ||
nodeKey: crypto.PrivateKey |
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.
We indeed have an appKey
if it's used to setup both the discovery and the node. The appKey
is then used to initialise the (logically distinct) keys for the node and discv5 with the same value.
apps/wakunode2/app.nim
Outdated
@@ -94,8 +97,137 @@ func version*(app: App): string = | |||
|
|||
## Initialisation | |||
|
|||
proc networkConfiguration(conf: WakuNodeConf): NetConfigResult = |
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.
Not entirely sure I agree. These procs are concerned with translating the already-initialised config to interpreted config types that are specific to the app. In contrast, config.nim
is only interested in parsing and initialising external config and is already complex enough as is without more app constructs. I'd be happy if we move these two functions to a new network_config.nim
module to keep app.nim
cleaner, but happy to go with majority opinion here. :)
var node: WakuNode | ||
|
||
let pStorage = if peerStore.isNone(): nil | ||
else: peerStore.get() | ||
|
||
let rng = crypto.newRng() |
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.
Mmm. Wait, was this rng generation redundant before as it's also an argument for this function?
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 that's what I concluded.
|
15b521e
to
81d2d56
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.
Hey! I approve now so that I don't block the upcoming PR. I think it will get much clearer by then :)
Thanks for this!
Description
Setting the code for the move of discv5 out of node. Note that some changes might look weird without context, feel free to ask.
Changes
tracking #1812