Watch
0
0
Fork
You've already forked hyperhive
0

hive-c0re: its otel exporter goes to the bridge, not the swarm upstream

This commit is contained in:
atlas 2026-10-21 12:50:06 +02:00
commit 013bbe5adc
2 changed files with 9 additions and 11 deletions

View file

@ -143,13 +143,11 @@ in
# contain. The queue's TLS is verified against `HIVE_C0RE_OIDC_CA_FILE`
# (../glue-hive-tls-controllers.nix), not this bundle.
#
# ⚠️ `SSL_CERT_FILE` REPLACES the trust store, and unlike the other
# consumers of this helper, hive-c0re already makes a *public*-TLS call:
# the OTEL exporter reaches whatever
# `deploy.swarm-otel.upstream.endpoint` names, typically a
# normal internet host. The bundle is system CAs + the store's root
# precisely so that path keeps working — narrowing it to the store's root
# alone would fix a case nobody hits yet and break one that runs today.
# ⚠️ `SSL_CERT_FILE` REPLACES the trust store, so the bundle is system
# CAs + the store's root: narrowing it to the root alone would break any
# public-TLS call this daemon makes. Its OTEL exporter is not one: it
# posts plain http to the bridge collector. Only the swarm-otel collector
# reaches `deploy.swarm-otel.upstream.endpoint`.
(caTrust.trustBundle {
inherit pkgs;
name = "hive-c0re";