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

Reimplement LivenessCheck and ReadinessCheck as plugins #7704

Open
lu-pinto opened this issue Oct 1, 2024 · 2 comments
Open

Reimplement LivenessCheck and ReadinessCheck as plugins #7704

lu-pinto opened this issue Oct 1, 2024 · 2 comments
Labels
good first issue Good for newcomers

Comments

@lu-pinto
Copy link
Contributor

lu-pinto commented Oct 1, 2024

Description

I noticed, while working on a plugin that required to extend the ReadinessCheck, that this check is implemented not through plugins but hardcoded as an RPC method during initialization.
It would be much cleaner if these checks can be implemented as plugins, as in the future if someone needs to do something similar, it would be easier and faster to do it.

  • LivenessCheck is a trivial probe to check if process is UP or DOWN
  • ReadinessCheck requires 2 checks:
  1. Make sure that the sync is within a certain distance from the head of the chain. For this, a numMaxBlocksBehind parameter is used to check for distance. This check could be done in the plugin version by registering an BesuEvent for addSyncStatusListener(SyncStatusListener).
  2. Using a parameter minPeers check that the number of peers connected is higher than that value. In the plugin version, I can't see a way to have access to the number of peers but this could easily be exposed by P2PService.

Acceptance Criteria

Readinees and Liveness checks are re-implemented without side effects. Both probes will be functioning the same as before but now implemented as plugins.

@lu-pinto lu-pinto added the good first issue Good for newcomers label Oct 1, 2024
@7suyash7
Copy link
Contributor

7suyash7 commented Oct 2, 2024

Should this be implemented inside the plugins directory, with a new sub-directory called health-checks, or can they go inside the existing rocksdb directory?

@lu-pinto
Copy link
Contributor Author

lu-pinto commented Oct 3, 2024

IMO, we should go with a sub-directory inside plugins. health should be enough as a name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants