walterddr commented on issue #9023: URL: https://github.com/apache/pinot/issues/9023#issuecomment-1191559119
ENUM type in Response vs. Different end points == IMO it is best to use different endpoints instead of the same endpoint with varying types of response - [HTTP Response Code](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#successful_responses) does suggest that any 200-299 is considered a success, we can potentially encode that along with the different acceptable success stats. But it would be a very non-traditional way of using the HTTP response code. - [Container Management in K8s](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) provides the liveness/readiness/startup probes specifically to differentiate different type of condition of the container pod, but I am not seeing any customization to allow parsing of the response content. Some Thoughts == - Initially, this issue is created to deal with running Pinot on K8s, while debugging a slow pod restart failure. thus I added the `health/instance` for liveness probe; and use the normal `health` for readiness probe. - I've also discovered that when the slow pod restart returns a 404 (BAD) state. It doesn't tell me exactly which segment was slow loading for which table. thus I added the additional endpoint `health/service` to return the entire service status callback map. Seems like it is causing some confusion and addressing both issues at the same time also distract the discussion. So I would say let's focus on the main purpose of the discussion to find a way to allow containerization software to know whether a pinot server is alive vs. a pinot server is ready for serving queries. if there's a way to easily configure k8s or ELB to differentiate the 2 server state. I am ok with using just one endpoint. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
