Allow setting of serving-status about grpchealth-go HOT 3 CLOSED

One example use-case is to let a Kubernetes livenessProbe run against one service default or liveness that can be set to true immediately, while letting a Kubernetes readynessProbe run against the exposed gRPC/Connect service-name (e.g. acme.user.v1.UserService).

This way, we can start the Connect-server immediately on startup, with the defaultservice being set to healthy (so that Kubernetes does not kill the app while starting up), and then run some long-running initialization-procedures (like reading a big file into memory, or doing some initial DB-querying for in-memory-caching), before setting the acme.user.v1.UserService-service to healthy.

This will allow Kubernetes to start our pod, but not serve any traffic to it until we are done initializing the service.

from grpchealth-go.

Sorry for the late response; I somehow completely missed this issue 😬 Very little about the grpc/health package appeals to me - particularly the init-time side effect - but I'm certainly open to adding some functionality here.

My concern with adding a simple bag of state as a dynamic Checker implementation is that it doesn't seem to simplify the problem much. If you're interested in dynamic health, you're probably actively checking the health of some downstream system (for example, pinging your database). In that case, you probably want to run your probes on a schedule and cache the result - querying downstream systems for each health check gets expensive quickly. Wouldn't it be better to encapsulate this whole process?

from grpchealth-go.

@bendiktv2 Sorry for the long delay! Opened a PR that addresses this issue as part of getting us to a stable release.

from grpchealth-go.