Why
We're migrating our platform from PHP 7 to PHP 8, and the Aerospike
Connection Manager (ACM) + PHP client are on the critical path. To run ACM as a
first-class production service we need a few things it doesn't have today:
metrics, health/readiness endpoints, graceful shutdown, and a couple of startup
fixes (the Docker image and packaged systemd unit pass a flag the binary
doesn't define, so they can't actually start).
We've standardized our stack on Aerospike and this client, so ACM's
production-readiness directly gates ours — and we'd much rather build on and
contribute back upstream than maintain a private fork. For testing we're
currently patching ACM, but we want these changes to land in open source.
What we'd like to add
- Cluster config reader refactored onto
knadh/koanf, plus an explicit [clusters.<name>] namespace (legacy top-level tables still work, with a deprecation notice)
- Layered management config:
defaults < TOML < env < CLI flags
- Prometheus metrics (Go runtime, process, gRPC, Aerospike connection pool)
- Kubernetes-style probes:
/livez, /readyz, /healthz (+ opt-in pprof) on one admin port
- Graceful shutdown, structured logging, container/service fixes, docs
All opt-in, backward compatible, and covered by tests.
The ask
A working branch is ready (#77). It's intentionally one PR with focused
commits so the overall direction is visible end to end — I expect the actual
merge to happen as several smaller PRs, and I'm happy to split it that way.
At this stage I'm mainly looking for a design-level review: does this
direction and shape look right to you? Any comments are very welcome and I'll
rework things to match whatever we agree on before merging.
This is just the start — there's planned follow-up on the Rust extension and
further ACM work too. Would really appreciate your guidance and support.
Why
We're migrating our platform from PHP 7 to PHP 8, and the Aerospike
Connection Manager (ACM) + PHP client are on the critical path. To run ACM as a
first-class production service we need a few things it doesn't have today:
metrics, health/readiness endpoints, graceful shutdown, and a couple of startup
fixes (the Docker image and packaged systemd unit pass a flag the binary
doesn't define, so they can't actually start).
We've standardized our stack on Aerospike and this client, so ACM's
production-readiness directly gates ours — and we'd much rather build on and
contribute back upstream than maintain a private fork. For testing we're
currently patching ACM, but we want these changes to land in open source.
What we'd like to add
knadh/koanf, plus an explicit[clusters.<name>]namespace (legacy top-level tables still work, with a deprecation notice)defaults < TOML < env < CLI flags/livez,/readyz,/healthz(+ opt-in pprof) on one admin portAll opt-in, backward compatible, and covered by tests.
The ask
A working branch is ready (#77). It's intentionally one PR with focused
commits so the overall direction is visible end to end — I expect the actual
merge to happen as several smaller PRs, and I'm happy to split it that way.
At this stage I'm mainly looking for a design-level review: does this
direction and shape look right to you? Any comments are very welcome and I'll
rework things to match whatever we agree on before merging.
This is just the start — there's planned follow-up on the Rust extension and
further ACM work too. Would really appreciate your guidance and support.