Hi Akshaya, Thanks for chiming in. At first glance, I think this is a reasonable use case to cover. However, Flight does try to be independent of gRPC. So maybe the approach would be to define a "Flight health check" that would map to gRPC health check when using gRPC, and something else when not (for UCX, presumably a custom method). And the only other complication would be making this opt-in to avoid conflicting with existing applications.
That does mean we wouldn't be exposing the full breadth of the gRPC health check API. But Python would be covered and we could avoid having to redefine this all the time. -David On Mon, Oct 3, 2022, at 17:39, Akshaya Annavajhala (AK) wrote: > Hello, I was helpfully redirected by David from [ARROW-17920] Built-in > GRPC health checks in FlightServerBase - ASF JIRA > (apache.org)<https://issues.apache.org/jira/browse/ARROW-17920> to the > mailing list to discuss how a consumer of FlightServerBase might > meaningfully implement probe endpoints/health checks for production > environments more easily. > > The issue links to a related previous item that adds a C++ example for > running multiple GRPC servers behind the same > port<https://github.com/apache/arrow/pull/11524> which I can translate > simply into a side-by-side health service and FSB in the same > application. However, the > issue<https://issues.apache.org/jira/browse/ARROW-14440> notes this > same technique is unavailable to python (implementations of > FlightServerBase) and the separate servers implies a lack of comingling > logic related to the flight server itself and the health check, > effectively making the health probes very dumb logic/check box > implementation. > > In the issue I opened, I proposed built-in gRPC health check > protocol<https://github.com/grpc/grpc/blob/master/doc/health-checking.md#grpc-health-checking-protocol> > > in the native FSB that would thus apply to a "simple" python derivation > without modifications as well as perhaps in the future allowing the > python space to override the implementation (similar to do_*) for more > advanced use cases that might require extensive python space > initialization, etc. > > I'd love to hear others' thoughts on the high-level > direction/alternatives on this topic! > > Regards, > AK
