Skip to content
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

Test Obol commands on Gnosis clusters #3093

Open
6 tasks
boulder225 opened this issue May 22, 2024 · 2 comments
Open
6 tasks

Test Obol commands on Gnosis clusters #3093

boulder225 opened this issue May 22, 2024 · 2 comments
Assignees

Comments

@boulder225
Copy link
Collaborator

boulder225 commented May 22, 2024

🎯 Problem to be solved

Testing Obol commands on Gnosis chain testnet clusters

🛠️ Proposed solution

  • Reach out to potential Gnosis chain node operators with cluster config form https://docs.google.com/forms/d/e/1FAIpQLSewiiUOGGXrNpSosW2MPWziMYKV0yfIQRneGLFuSzi0o2Ahtg/viewform
  • Ask them for their current node setup details (locations, specs, number of keys)
  • Schedule a time for all operators to run the test ping commands simultaneously
  • Evaluate feedback and pivot cluster setup if needed, based on latencies observed
  • After ping commands, proceed with testing beacon node commands if successful
  • Determine criteria for assessing "good enough" performance on Gnosis, since Obol monitoring may not cover Gnosis-specific metrics currently

Included Test Commands in the current rc1

  • test peers
    -- Ping
    -- PingMeasure
    -- PingLoad
    -- IsLibp2pPortOpen
  • test beacon
    -- Ping
    -- PingMeasure
    -- IsSynced
    -- PeerCount
@boulder225
Copy link
Collaborator Author

Hey team! Please add your planning poker estimate with Zenhub @gsora @KaloyanTanev @pinebit

@OisinKyne
Copy link
Contributor

  • no testnet, straight to gnosis mainnet
  • form is posted in #biz-partnerships slack. gets tentative node locations + buy in.
  • once agreed, we will get them to create ENRs and report them to us, ideally with more firm node details for our CRM. We'll decide the two clusters.
  • we send the two clusters separate cal invites and in the description we say "run this command at this time if you can't attend" . We attend the call and watch/learn/debug.
  • If all goes to plan we send them the invites? Maybe there and then? and get them through DKG?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants