hydra-notify fails to listen on IPv6 for Prometheus metrics.
To Reproduce
configure hydra-notify as follows:
<hydra_notify>
<prometheus>
listen_address = ::1
port = 9199
</prometheus>
</hydra_notify>
Expected behavior
Service listens on IPv6.
Actual behaviour
Starting the Prometheus exporter, listening on http://[::1]:9199/metrics.
failed to listen to port 9199: Invalid argument at /nix/store/vs5db18kx919dgbnz1akfq4d5wf28m5f-hydra-perl-deps/lib/perl5/site_perl/5.38.2/HTTP/Server/PSGI.pm line 103.
(using ::1 or [::1] does not make a difference)
Hydra Server:
Please fill out this data as well as you can, but don't worry if you can't -- just do your best.
OS and version: NixOS 24.05
Version of Hydra: d7986226f0666d5aa0032fdcdb9f38eef6a91dd3
Version of Nix Hydra is built against: Nix 2.22
Version of the Nix daemon: Lix 2.90.0
Additional context
I'm not a Perl person but upstream code looks like you need to pass an explicit ipv6 argument to the webserver to get IPv6, which hydra-notify is not doing.
Considering that this is literally the only place in which promCfg is used, why not just pass the entire promCfg uhh.… (map? table? dict? hash? object?) the entire thing to that upstream code so that users can override whatever they want including certificates or whatnot (or ipv6 = 1), though doing that as-is would definitely break downstream considering that host ≠ listen_address. But passing the rest of the values on would be nice.
Describe the bug
hydra-notify fails to listen on IPv6 for Prometheus metrics.
To Reproduce
Expected behavior
Service listens on IPv6.
Actual behaviour
(using
::1
or[::1]
does not make a difference)Hydra Server:
Please fill out this data as well as you can, but don't worry if you can't -- just do your best.
Additional context
I'm not a Perl person but upstream code looks like you need to pass an explicit ipv6 argument to the webserver to get IPv6, which hydra-notify is not doing. Considering that this is literally the only place in which
promCfg
is used, why not just pass the entirepromCfg
uhh.… (map? table? dict? hash? object?) the entire thing to that upstream code so that users can override whatever they want including certificates or whatnot (oripv6 = 1
), though doing that as-is would definitely break downstream considering thathost
≠listen_address
. But passing the rest of the values on would be nice.