Add or document livelihood/readiness endpoints for the Trigger Service

What is the problem you want to solve?

I would like to be able to use widely used tools (e.g. Kubernetes) to manage Trigger Service instances so that I can effectively achieve high availability of the service on my deployment.

What is the solution you would propose?

Add a /readyz and /livez endpoint like the HTTP JSON API Service.

Describe alternatives you’ve considered

Using another endpoint to check for the livelihood of the service, but I’m not sure about which one could be used to this end. If the problem can be solved that way, I’d find it satisfactory to document this.

[garyverhaegen-da]

FYI /livez is already documented. I see no reference to /readyz in either docs or source.

[stefanobaghino-da]

The main reason to have a readyz endpoint is to enable customers using standard container orchestration tooling i.e. Kubernetes. I would recommend to:

• add a readyz endpoint
• ensure that the behavior of the livez endpoint matches the semantics expected by Kubernetes

Both points are important to enable users to operate a fleet of containers running Daml runtime components.