Skip to content

Add BBS-connectivity health check to auctioneer - #1186

Open
ivo1116 wants to merge 1 commit into
cloudfoundry:developfrom
ivo1116:auctioneer-bbs-health-check
Open

Add BBS-connectivity health check to auctioneer#1186
ivo1116 wants to merge 1 commit into
cloudfoundry:developfrom
ivo1116:auctioneer-bbs-health-check

Conversation

@ivo1116

@ivo1116 ivo1116 commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

Summary

Adds an optional enable_bbs_health_check runner to the auctioneer. When enabled, the auctioneer periodically probes BBS via bbs.Client.Ping() and exits after N consecutive failures. Monit then restarts it, and the normal SIGTERM path releases the auctioneer's Locket lock cleanly so a healthy-AZ standby can acquire leadership.

Disabled by default — no behavior change unless the property is set.

Motivation

The auctioneer's Locket lock is renewed over a persistent gRPC connection to Locket, whose DB path is served from a warm connection pool — DNS-free.

Auction work, in contrast, resolves bbs.service.cf.internal on every call — DNS-dependent.

Under a DNS-only partition, renewals keep succeeding while the leader can't do any actual work. The two paths share no state, so the process does not self-evict and the Locket lock's 15-second TTL is continuously bumped forward. A functionally-dead leader retains the lock indefinitely, blocking failover.

This PR is the auctioneer analog of the BBS enable_db_health_check pattern.

Configuration

Property Default Purpose
diego.auctioneer.enable_bbs_health_check false Master toggle — off preserves current behavior
diego.auctioneer.bbs_health_check_interval 10s Time between probes
diego.auctioneer.bbs_health_check_timeout 5s Per-probe timeout
diego.auctioneer.bbs_health_check_failure_threshold 3 Consecutive failures before exit

Worst-case detection latency = interval × threshold.

Implementation

  • New file: src/code.cloudfoundry.org/auctioneer/cmd/auctioneer/bbs_health_check_runner.go — the ifrit runner.
  • Config additions in cmd/auctioneer/config/config.go.
  • Wired into the ifrit Members group in cmd/auctioneer/main.go behind cfg.EnableBBSHealthCheck.
  • BOSH job property additions in jobs/auctioneer/spec and template wiring in jobs/auctioneer/templates/auctioneer.json.erb.

Uses the existing bbs.Client.Ping(logger, traceID) method — same DNS/TLS/HTTP path the auction code uses, so functional degradation manifests identically to the health check.

The probe is wrapped in a context.WithTimeout so a hung Ping cannot stall the health-check goroutine. Recovery is logged as bbs-health-check.recovered when a probe succeeds after prior failures, resetting the counter.

Tests

Two Go unit tests in bbs_health_check_runner_test.go using a fake bbs.Client and fakeclock:

  • TestBBSHealthCheckRunner_ExitsOnThreshold — the runner returns a non-nil error after failureThreshold consecutive failed probes.
  • TestBBSHealthCheckRunner_RecoversOnSuccess — a successful probe resets the counter and the runner continues.

Adds an optional ifrit runner that periodically probes BBS via
`bbs.Client.Ping()`. On N consecutive failures the auctioneer exits,
letting monit restart it so its Locket lock is released cleanly and
a healthy-AZ standby can acquire leadership.

Motivation
----------
Under a DNS-only partition affecting `bbs.service.cf.internal`, the
auctioneer's Locket lock renewal path (persistent gRPC connection,
Locket-side pooled DB connections) keeps succeeding while its
functional path (fresh DNS per auction request to BBS) fails on every
call. The two paths share no state, so a functionally-dead leader
retains the lock indefinitely.

Fix
---
Auctioneer analog of the BBS `enable_db_health_check` pattern: a
runner in the ifrit group that exits the process on consecutive Ping
failures so the normal SIGTERM path releases the Locket lock.

Configuration (all disabled by default to preserve current behavior)
- diego.auctioneer.enable_bbs_health_check (default: false)
- diego.auctioneer.bbs_health_check_interval (default: 10s)
- diego.auctioneer.bbs_health_check_timeout (default: 5s)
- diego.auctioneer.bbs_health_check_failure_threshold (default: 3)

Worst-case detection latency is interval * threshold.

Testing
-------
Two Go unit tests cover the threshold-exit and recovery paths using a
fake bbs.Client and a fakeclock.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Development

Successfully merging this pull request may close these issues.

1 participant