Allow the `--beacon-nodes` list to be updated at runtime

[macladson]

Proposed Changes

Adds a new /lighthouse API call to the VC which allows the list of beacon nodes to be updated dynamically at runtime.

An entirely new beacon node list is provided to the VC so it effectively adds, removes or reorders nodes to match the new list.

This can then be used in Siren, which will enable a "drag to reorder" system along with adding and removing beacon nodes while the VC is on. This will make it unnecessary to reboot the VC when users want to simply add or remove a BN from the list.

Usage

curl -X POST http://127.0.0.1:5062/lighthouse/beacon/update \
 -H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" \
 -H "Content-Type: application/json" \
 -d "{\"beacon_nodes\":[\"http://beacon-node1:5052\",\"http://beacon-node2:5052\",\"http://beacon-node3:5052\"]}" | jq

The new nodes should start appearing in the VC logs, but you can also check which nodes the VC is connected to using:

curl -X GET http://127.0.0.1:5062/lighthouse/ui/fallback_health -H "Authorization: Bearer $(cat ${DATADIR}/validators/api-token.txt)" | jq

Additional Information

The current design rebuilds the candidate list from scratch and then swaps it in. While I don't expect this process to take a long time, it's possible some API queries will fail during the swap over. Another option is to mutate the list in place, which prevents BNs which are present in both the old and new lists from being removed.

[macladson]

Thanks for the review!

Would it be possible to have a check on the beacon nodes used in the --beacon-nodes flag to check the existence of the beacon node in the POST query? That would be nice as it will prevent incorrect POST query to succeed.

I think liveness checking each beacon node is beyond the scope of this API. So long as each value is a valid URL, the beacon node could become "online" at any time so it should be added to the list. I think it makes sense that it is up to the user to provide beacon nodes which are running, just like it is up to the user to provide beacon nodes to the --beacon-nodes CLI flag.

Note that the API will error in the event a value is not a valid URL, or if the list is empty.

[mrabino1]

Is there a target release number to have this functionality pulled in?

[michaelsproul]

Added to v6.1.0

[mergify[bot]]

This pull request has merge conflicts. Could you please resolve them @macladson? 🙏

[michaelsproul]

@mrabino1 Just an update: this didn't make the cut for v7.0.0, our Electra-on-mainnet release. But it will be in v7.1.0 shortly after that.

[mrabino1]

@michaelsproul All good ! Thank you.. Respect !

[mergify[bot]]

This pull request has merge conflicts. Could you please resolve them @macladson? 🙏

[mergify[bot]]

This pull request has been removed from the queue for the following reason: checks failed.

The merge conditions cannot be satisfied due to failing checks:

• ☑️ test-suite-success

You can check the last failing draft PR here: #7627.

You may have to fix your CI before adding the pull request to the queue again. If you update this pull request, to fix the CI, it will automatically be requeued once the queue conditions match again. If you think this was a flaky issue instead, you can requeue the pull request, without updating it, by posting a @mergifyio requeue comment.

[michaelsproul]

@mergify requeue

[mergify[bot]]

requeue

✅ The queue state of this pull request has been cleaned. It can be re-embarked automatically