jdef
commented
6 years ago @chakri-nelluri @saad-ali something that I find interesting about the gRPC health check protocol is that there's an OPTIONAL service name in the request, which allows for (optionally) more granular, per-service level health checks. For example, if a plugin instance implemented controller and node services, and the Probe RPC supported a similar, optional service name in the request, then a CO could be configured to probe the health of the controller and node services independently. In the end, for CSI, I'm not convinced that this would be a huge win (yet) because the only thing a CO can do w/ an unhealthy plugin is to respawn it -- strategy is independent of which specific gRPC service is failing. Or am I missing something obvious?
Anyway, since we've simplified the API, we can always add an optional service name to the Probe request at some later point, if needed, without breaking the API.
Today, we have Identity service which establishes the identity and discovers the list of supported versions. Also, a service can crash and spin back up anytime and the error codes defined in the probe can ideally be returned for any RPC call. Given that do we really need a Probe call? Can we just use Identity service to establish the identity and readiness of the plugin?