nix: split statusPublish and the otel secret into deploy.*
Slices 8 and 9 of the swarm/deploy split, and the last two. statusPublish had three coordinates under one namespace. Two of them are this machine's — where the queue listens *as seen from here*, and where its client secret sits on this disk — so they move to `deploy.hive-controller.statusPublish.*`, the namespace of the daemon that is their only reader. `tokenEndpoint` is the swarm's one address, so it stays. That leaves `swarm.statusPublish` holding a single option: a legitimate split, not a botched move. The all-or-nothing assertion now spans both namespaces. It is repointed in both its condition and its message, and the message spells all three paths in full so an operator is never told to set two options under a path that only has one. `environment.nix`'s guard and the value beside it likewise read different namespaces on purpose. The collector's secret moves the same way, for the same reason, to `deploy.swarm-otel.*` — `enable` already lives there. That also retires one of the eight cross-namespace assignments tracked in #4048: the delivery unit set a `swarm.*` value under a `deploy.*` gate, and now sets a `deploy.*` value under one. module-eval gets a fixture per slice. `otelRemoteAuthelia` already set the collector secret through its pre-rename path, so it becomes slice 9's old-path case as it stands — left spelled that way deliberately, with a comment, so it is not read later as a missed site. That fixture also turned out to be describing an impossible hive: it said authelia lives elsewhere without saying where, so the authenticator interpolated a null `swarm.authelia.url` into its `token_url`. Nothing to do with the rename, and invisible to the existing case over the same fixture, which reads `? auth` and `elem` — both stop at names and never force the extension's value. Given the address a remote-IdP deployment has. Verified: 49 -> 51 properties, all holding.
This commit is contained in:
parent
2e1c15dc98
commit
01ce968fb6
8 changed files with 154 additions and 48 deletions
|
|
@ -213,7 +213,7 @@ let
|
|||
# not of where any other service runs. Not an assertion: a collector on a
|
||||
# host of its own is a supported shape, and refusing to build it would make
|
||||
# this fix illegal where the bug bites hardest.
|
||||
haveCollectorSecret = cfg.clientSecretFile != null;
|
||||
haveCollectorSecret = deployCfg.swarm-otel.clientSecretFile != null;
|
||||
|
||||
# The operator-configured upstream, named once: the same exporter carries
|
||||
# every signal, so metrics and logs both reach it without a second
|
||||
|
|
@ -497,7 +497,13 @@ in
|
|||
after the change that caused it evaluated cleanly.
|
||||
'';
|
||||
};
|
||||
};
|
||||
|
||||
# What stays above is what the collector IS to the swarm — the client it is
|
||||
# registered as, where it exports. The secret is a path on the machine that
|
||||
# runs it, so it hangs off the deployment. `enable` already lives in
|
||||
# ./deploy.nix, which also carries the rename.
|
||||
options.services.hyperhive.deploy.swarm-otel = {
|
||||
clientSecretFile = lib.mkOption {
|
||||
type = lib.types.nullOr lib.types.str;
|
||||
default = null;
|
||||
|
|
@ -630,7 +636,7 @@ in
|
|||
# authelia runs — it copies out of its container — so it is also what
|
||||
# names the file. `mkDefault`, so a deployment that delivers the secret
|
||||
# some other way just sets the option.
|
||||
services.hyperhive.swarm.otel.clientSecretFile = lib.mkIf deployCfg.authelia.enable (
|
||||
services.hyperhive.deploy.swarm-otel.clientSecretFile = lib.mkIf deployCfg.authelia.enable (
|
||||
lib.mkDefault collectorSecretInContainer
|
||||
);
|
||||
|
||||
|
|
@ -1428,7 +1434,7 @@ in
|
|||
# no authenticator is rendered either, so the collector starts and
|
||||
# is refused by the stores rather than failing to start.
|
||||
// lib.optionalAttrs haveCollectorSecret {
|
||||
LoadCredential = [ "${collectorCredentialId}:${cfg.clientSecretFile}" ];
|
||||
LoadCredential = [ "${collectorCredentialId}:${deployCfg.swarm-otel.clientSecretFile}" ];
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
Loading…
Reference in a new issue