deploy: name the swarm collector swarm-otel, not otel
Per review: `deploy.otel` does not imply swarm level, and there is a hive-tier collector too -- `services.hyperhive.otel.enable`, which every hive runs. The tier is the entire distinction between the two, so the name has to carry it, matching `deploy.swarm-controller` and `deploy.swarm-ui`. 15 swarm-tier references renamed across 8 files. The hive-tier collector's 16 references are deliberately untouched, verified as a control on the same command. Three spellings needed three different patterns, all inside this one rename: the dotted path; the `mkRenamedOptionModule` target written as a nix LIST (`[ ... "deploy" "otel" "enable" ]`), which no dotted grep can match; and prose in docs/observability.md spelled `deploy.otel` with neither `.enable` nor a leading dot. Unanchored `deploy\.otel\b` is the only pattern that finds all three.
This commit is contained in:
parent
13b1b41172
commit
09fe94a8ca
10 changed files with 24 additions and 23 deletions
|
|
@ -180,7 +180,7 @@ let
|
|||
collectLogs = logExporterNames != [ ];
|
||||
in
|
||||
{
|
||||
# `enable` moved to `services.hyperhive.deploy.otel.enable` — see ./deploy.nix.
|
||||
# `enable` moved to `services.hyperhive.deploy.swarm-otel.enable` — see ./deploy.nix.
|
||||
# ⚠️ That is the SWARM collector. The per-hive one keeps its own
|
||||
# `services.hyperhive.otel.enable` (./otel.nix) and is a different
|
||||
# option entirely — every hive runs that one.
|
||||
|
|
@ -435,8 +435,8 @@ in
|
|||
};
|
||||
};
|
||||
|
||||
config = lib.mkIf (config.services.hyperhive.enable && deployCfg.otel.enable) {
|
||||
# The gateway name, inside `deployCfg.otel.enable` — that guard is the load-bearing
|
||||
config = lib.mkIf (config.services.hyperhive.enable && deployCfg.swarm-otel.enable) {
|
||||
# The gateway name, inside `deployCfg.swarm-otel.enable` — that guard is the load-bearing
|
||||
# part. Every hive in a swarm may know this collector exists, but only
|
||||
# the host that RUNS it may claim the name; a client hive declaring the
|
||||
# vhost would answer for a service it does not have.
|
||||
|
|
@ -601,7 +601,7 @@ in
|
|||
# samples and drops them — which looks healthy and loses data.
|
||||
assertion = otelCfg.endpoint != "" || deployCfg.victoriametrics.enable;
|
||||
message = ''
|
||||
services.hyperhive.deploy.otel.enable is true but this collector
|
||||
services.hyperhive.deploy.swarm-otel.enable is true but this collector
|
||||
has nowhere to send what it receives:
|
||||
services.hyperhive.otel.endpoint is empty and
|
||||
services.hyperhive.deploy.victoriametrics.enable is false.
|
||||
|
|
@ -633,7 +633,7 @@ in
|
|||
# collector would listen on nothing while looking configured.
|
||||
assertion = hyperhiveCfg.swarm.hives != { };
|
||||
message = ''
|
||||
services.hyperhive.deploy.otel.enable is true but
|
||||
services.hyperhive.deploy.swarm-otel.enable is true but
|
||||
services.hyperhive.swarm.hives is empty: ingest is authenticated
|
||||
per hive, so an empty roster means this collector accepts nothing
|
||||
from anyone.
|
||||
|
|
@ -745,7 +745,7 @@ in
|
|||
# issuer URL evaluates cleanly and refuses every hive at runtime.
|
||||
assertion = autheliaCfg.url != null;
|
||||
message = ''
|
||||
services.hyperhive.deploy.otel.enable is true but
|
||||
services.hyperhive.deploy.swarm-otel.enable is true but
|
||||
services.hyperhive.swarm.authelia.url is null: every hive
|
||||
authenticates to this collector as itself, and the token comes
|
||||
from the swarm's identity provider.
|
||||
|
|
|
|||
Loading…
Reference in a new issue