-
Notifications
You must be signed in to change notification settings - Fork 2
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
[BN-1018] Add gRPC Health Check Proto #89
[BN-1018] Add gRPC Health Check Proto #89
Conversation
06c24cb
to
5ba84e3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great PR, some suggestions.
- files structure
- enumeration comments
Package names should be in lowercase. Package names should have unique names based on the project name, and possibly based on the path of the file containing the protocol buffer type definitions.
https://protobuf.dev/programming-guides/style/#packages
In other folders proto file are organized by service/models, maybe you can do something like this.
- proto
- health
- service
- health_rpc.proto
- models
- models.proto
- service
- health
models.proto
enum ServingStatus {
// UNKNOWN means that there was a timeout hitting the head of the chain..
UNKNOWN = 0;
// SERVING means that all services are running as expected
SERVING = 1;
// NOT_SERVING means...
NOT_SERVING = 2;
// SERVICE_UNKNOWN means, // Used only by the Watch method.
SERVICE_UNKNOWN = 3;
}
health_rpc.proto
syntax = "proto3";
package co.topl.health.services;
service Health {
rpc Check(HealthCheckRequest) returns (HealthCheckResponse);
rpc Watch(HealthCheckRequest) returns (stream HealthCheckResponse);
}
message HealthCheckRequest {
// service is a string that we must/should send for this reason.
string service = 1;
}
message HealthCheckResponse {
ServingStatus status = 1;
}
@nandotorterolo Thanks for the review! I'll update the folder format of the modes/services. One note though, I don't believe that the built in gRPC health check in Kubernetes supports customizing the package/service path. I believe it must be |
5ba84e3
to
1fc3f47
Compare
ok, I didn't know about Kubernetes customizations.
|
Yes, however the
Or whichever format makes more sense. |
## Purpose Implement gRPC health check for Node. ## Approach Build and implement the proto based on: https://github.com/grpc/grpc/blob/master/doc/health-checking.md The implementation uses a map to store the service statuses for Bifrost, Genus, and the overall status noted by an empty string `""`. This is a first pass as there is no logic for determining an unhealthy status for other services, but currently the Kubernetes gRPC liveliness and readiness probes only use the overall health for the health check. I believe this should cover most cases initially as long as Bifrost and Genus will throw errors (causing the Kubernetes pod to automatically restart itself), or if the gRPC server hosting goes down, the health check will get an unknown status and restart anyways. ## Testing * Deployed to GKE, verified that the gRPC health check normally reported healthy. * Verified the health check restarted the pods when an unhealthy status was returned. * Verified the health check restarted when nothing (an UKNOWN) status was returned. ~~## TODO~~ ~~Merge and use this PR's protobuf specs: Topl/protobuf-specs#89 Done! ## Tickets *
Purpose
Add health check proto.
Approach
The proto comes from: https://github.com/grpc/grpc/blob/master/doc/health-checking.md
Testing
Built locally, implemented in Bifrrost, deployed to GKE and ensured that the
grpc
liveliness/readiness probes succeeded.Tickets