Split the Roles in three types #5492
Conversation
tomaka
requested review from
Demi-Marie,
andresilva,
mxinden and
tomusdrw
as code owners
cecton
left a comment
cecton
left a comment
There was a problem hiding this comment.
This looks great! It seems simpler
…o compile on my machine
andresilva
left a comment
andresilva
left a comment
There was a problem hiding this comment.
Overall changes and logic LGTM. I still think we need to make the distinction more clear between network role and local role. Not sure if this is working properly right now due to the initial role setup.
|
I think the script doesn't like the fact that it's on my fork repo. I opened #5520 instead. |
| config.network.non_reserved_mode = NonReservedPeerMode::Deny; | ||
| } | ||
|
|
||
| config.network.sentry_nodes.extend(self.sentry_nodes.clone()); |
There was a problem hiding this comment.
@tomaka is it intended that you do not set NetworkConfiguration.sentry_nodes anymore??
There was a problem hiding this comment.
Oh I see, you removed sentry_nodes from NetworkConfiguration. But then why is it still in the cli??
There was a problem hiding this comment.
There was a problem hiding this comment.
Yeah I figured out. I think sentry_nodes should have been moved to runcmd. NetworkConfigurationParams is only supposed to populate the NetworkConfiguration. I've done it while fixing merge conflicts in #5271
6 participants
This PR splits the
Rolesbitfield in three:The existing
Roleshas been moved untouched into thesc_network::protocol::messagemodule, where it continues to represent the data that is transferred on the wire.sc_network::confignow contains a newRole(note the lack of 's') enum whose variants areFull,Light,SentryandAuthority. It is more robust to misuse, as one can only pass a list of sentry nodes when usingAuthority, and a valiator when usingSentry.The gossiping API now uses
ObservedRole, which is an enum that can be one ofFull,Light,OurSentry(for when you're a validator connecting to your sentry),OurGuardedValidator(for when you're a sentry connecting to your validator), orAuthority(for third-party validators).GrandPa has been adjusted to always gossip messages to nodes whose role is
OurSentryorOurGuardedValidator. This fixes some issues with validators not receiving GrandPa messages from their sentries. This change is the original reason for this PR.Additionally, the
--sentryCLI option now accepts a multiaddress as parameter, representing the address of the validator we're protecting. This is a CLI breaking change.While modifying the CLI code, I encountered some issues with how to properly build a
Role::Authoritywhen the parameter of--sentryis aString.To fix that, I changed various
Stringsin the structopt structs insc_clito instead contain aMultiaddrorMultiaddrWithPeerId(a new type introduced in this PR).Some other minor changes:
client/rpc/api/system::NodeRolenow contains aSentryvariant. In other words, querying the node role from the RPC endpoint will now return "sentry" for sentries.authority_discoverynow accepts aVec<MultiaddrWithPeerId>instead of aVec<String>in accordance with the changes in the CLI.node_rolePrometheus metric will now contain the value3for sentries, rather than4(4 meaning "authority").polkadot companion: paritytech/polkadot#960