OneDev currently does not appear to provide dedicated health/readiness endpoints suitable for Kubernetes livenessProbe and readinessProbe.

Using an application endpoint such as /~login for the probes is problematic during maintenance and upgrade operations. OneDev intentionally becomes unavailable while performing maintenance, causing the endpoint to fail. If this endpoint is used as a liveness probe, Kubernetes may restart the pod while the maintenance operation is still running.

This can interrupt the maintenance operation and potentially leave the OneDev instance in an inconsistent state.

It would be useful to provide dedicated endpoints such as:

/healthz
/readyz

with semantics suitable for Kubernetes:

• /healthz — indicates whether the OneDev process is alive and should not be restarted by Kubernetes. It should remain successful during maintenance operations where possible.
• /readyz — indicates whether OneDev is ready to serve normal traffic. This may return a non-success status while OneDev is starting up or performing maintenance.
• The endpoints should ideally be unauthenticated and lightweight.
• The endpoints should not depend on the normal OneDev UI/login flow.

This would allow deployments to use:

livenessProbe:
  httpGet:
    path: /healthz
    port: 6610

readinessProbe:
  httpGet:
    path: /readyz
    port: 6610

The distinction between liveness and readiness is important here: maintenance should generally make the instance unready, but should not cause Kubernetes to restart it.

A dedicated health endpoint would make OneDev safer to operate in Kubernetes, particularly during upgrades and database migrations.