Manually tracked peers #521
Conversation
michaelkaplan13
requested review from
iansuvak,
geoff-vball,
bernard-avalabs and
cam-schultz
|
|
| @@ -165,6 +173,9 @@ func (n *appRequestNetwork) ConnectPeers(nodeIDs set.Set[ids.NodeID]) set.Set[id | |||
| return nil | |||
| } | |||
|
|
|||
| // Add manually tracked peers | |||
| peers = append(peers, n.manuallyTrackedPeers...) | |||
There was a problem hiding this comment.
I assume the system will behave correctly even if a peer appears more than once in the peers list (i.e., both returned by infoAPI.peers and is a member of the manuallyTrackedPeers).
looking at the PR I don't think that |
It was a requirement to make the Uptime interface match what is expected by other dependencies. Now that v1.11.12 is out though that interface is merged to master so we can update this to use that version of avalanchego |
Why this should be merged
Supercedes #519.
For development and testing purposes, it should be easy to create L1s on the Etna Devnet and Fuji using a single local validator node. Assuming the machine running single validator is not other publicly accessible then the validator will not be discovered by the
info.PeersRPC. This allows for a basic work around to still be able to create aggregate signatures from these L1s by providing an explicit list of peers that should be connected to from the aggregator.Note: Medium term, we should make
Networkan interface and allow any implementation to be provided to the aggregator. That way use cases can more cleanly/extensibly implement their own validator peer discovery mechanisms. This is just a shorter term work around.How this works
Adds
manuallyTrackedPeersto theappRequestNetwork, and allows it to be set viaNewNetwork. The aggregator will always attempt to connect to these peers whether or not they are included in theinfo.Peersresult.How this was tested
Through usage in the CLI
How is this documented
Comments