vinzenz/hyperhive
vinzenz/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

swarm-controller: extract jobq_metrics into its own hive-jobq-metrics crate

Browse source
This commit is contained in:
damocles 2026-08-19 17:52:12 +02:00 • committed by mara
commit f5ff8698f3
7 changed files with 100 additions and 59 deletions
Download patch file Download diff file Expand all files Collapse all files

12
swarm-controller/Cargo.toml
View file

@ -38,12 +38,12 @@ problem_details = { version = "0.9.0", features = ["axum"] }
# same shape `hive-c0re/src/job_queue/scheduler.rs` uses over its own graph.
hive-jobq.workspace = true
hive-jobq-wire.workspace = true
# OTEL SDK for the jobq-rollup metrics exporter (`jobq_metrics.rs`), from
# the workspace base — see the root Cargo.toml's comment for the
# blocking-client rationale shared by every OTEL-pushing crate.
opentelemetry.workspace = true
opentelemetry_sdk.workspace = true
opentelemetry-otlp.workspace = true
# The jobq-rollup OTEL exporter, wired up in `main` via
# `hive_jobq_metrics::spawn_exporter` — moved to its own crate (rather than
# living here as `jobq_metrics.rs`) specifically so a future second caller
# (e.g. hive-c0re, for its own per-hive job graph) doesn't have to depend on
# this whole binary to reuse it.
hive-jobq-metrics.workspace = true
# The forge webhook HMAC (`webhook.rs`). Kept in this crate rather than
# shared with hive-c0re's equivalent: c0re's copy is scheduled to be deleted
# with its webhook routes once registration moves here, so the second holder