Health check via /healthz endpoint

[geekdave]

Just wondering if anyone has a preferred liveness probe / healthcheck command to ensure that a git-sync sidecar is healthy. Without this, it seems there could be a risk of the git-sync sidecar silently failing, causing an expected config change not to be delivered.

[thockin]

I would be open to a PR which added an optional HTTP server inside git-sync, with some configurable heuristics for what constitutes failure. Alternately we already have (in master) `-max-sync-failures` which you can set to 1 or 2. That should trigger a crash of git-sync, which will be flagged by kubernetes. Less friendly, but workable.

…

On Mon, Oct 1, 2018 at 10:18 PM Dave Cadwallader ***@***.***> wrote: Just wondering if anyone has a preferred liveness probe / healthcheck command to ensure that a git-sync sidecar is healthy. Without this, it seems there could be a risk of the git-sync sidecar silently failing, causing an expected config change not to be delivered. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#113>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVDQVRN2J3yRUcuDZxi6G2IrHjvrAks5ugvc4gaJpZM4XDWNN> .

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[thockin]

/lifecycle frozen
/remove-lifecycle stale

[jacksontj]

A very basic liveliness probe is (hopefully) being added in #135
So this issue likely should move to being the health-check issue to cover what heuristics/config/etc. we want to control what constitutes "healthy".