-
-
Notifications
You must be signed in to change notification settings - Fork 628
grpc: Enable client-side health_v1 health checking #8254
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
Conversation
89cb066
to
587bad5
Compare
495d54f
to
9c668a6
Compare
9c668a6
to
e0f5518
Compare
Apologies for the force push. |
@beautifulentropy, this PR appears to contain configuration and/or SQL schema changes. Please ensure that a corresponding deployment ticket has been filed with the new values. |
5b303ba
to
4ea0d57
Compare
None of these changes necessitate a corresponding change by SRE before deployment. The removal of service specific checks is being tracked in IN-11451. |
e70f452
to
1d0efc3
Compare
I have pushed the Consul changes to #8261 because a CI flake just occurred in: https://github.com/letsencrypt/boulder/actions/runs/15716828209/job/44288499469 We'll need to work on having startservers.py actually check whether endpoints are up before beginning tests. |
- Configure all gRPC clients to check the overall serving status of each endpoint via the `grpc_health_v1` service. - Configure all gRPC servers to expose the `grpc_health_v1` service to any client permitted to access one of the server’s services. - Modify long-running, deep health checks to set and transition the overall (empty string) health status of the gRPC server in addition to the specific service they were configured for. Fixes letsencrypt#8227 (cherry picked from commit 1bfc318)
grpc_health_v1
service.grpc_health_v1
service to any client permitted to access one of the server’s services.Fixes #8227