| 14 Feb 2022 |
 @grahamc:nixos.org | nice | 14:15:18 |
| @grahamc:nixos.org | I'm hoping we could add a proper exporter directly to the evaluator and queue runner some day, but this looks great | 14:15:37 |
 das_j | yeah I was hoping the evaluator somehow dumps its state into the db as well but I couldn't find anything | 14:16:19 |
| @grahamc:nixos.org | one tricky bit of that is of course the process breakdown of hydra-evaulator calling hydra-evaluate-jobset calling hydra-eval-jobs, and potentially each of these could feasibly contain their own exporter, which would also be weird | 14:27:52 |
| das_j | What about this: The main daemon opens a fd for its subprocesses (FD 5 or something), and the subprocesses write their metrics there, maybe as kv pairs? Would be shitty but better than nothing | 14:29:04 |
| das_j | The main process can then collect these and serve them | 14:29:27 |
| @grahamc:nixos.org | I've tried to do that for ofborg in the past but was sort of a mess | 14:29:31 |
| @grahamc:nixos.org | but that was quite a bit more complicated | 14:29:55 |
| das_j | or each component just writes its stats into the main db and we scrape from there | 14:29:59 |
| @grahamc:nixos.org | so it could very well work here | 14:30:00 |
|  @pedrohlc:mozilla.org joined the room. | 15:13:45 |
| 15 Feb 2022 |
|  @packetgrill:automattic.com joined the room. | 13:32:31 |
 @linus.heckemann:matrix.mayflower.de | So I'm trying to update the hydra package in nixpkgs, and ran into migrations failing because the pgcrypto postgres extension was missing. Seems odd to me though that this wouldn't have been caught by NixOS tests. Has everyone who runs a hyra done CREATE EXTENSION pgcrypto; manually, or am I missing a place where that's done within hydra (a plain rg pgcrypto on the hydra repo didn't yield any results), or what might be happening here? | 16:45:49 |
| @linus.heckemann:matrix.mayflower.de | * So I'm trying to update the hydra package in nixpkgs, and ran into migrations failing because the pgcrypto postgres extension was missing. Seems odd to me though that this wouldn't have been caught by NixOS tests. Has everyone who runs a Hydra done CREATE EXTENSION pgcrypto; manually, or am I missing a place where that's done within hydra (a plain rg pgcrypto on the hydra repo didn't yield any results), or what might be happening here? | 16:45:55 |
| @linus.heckemann:matrix.mayflower.de | Aah, apparently gen_random_uuid() is built into postgres starting from 13.x | 16:49:57 |
| das_j | In reply to @linus.heckemann:matrix.mayflower.de
So I'm trying to update the hydra package in nixpkgs, and ran into migrations failing because the pgcrypto postgres extension was missing. Seems odd to me though that this wouldn't have been caught by NixOS tests. Has everyone who runs a Hydra done CREATE EXTENSION pgcrypto; manually, or am I missing a place where that's done within hydra (a plain rg pgcrypto on the hydra repo didn't yield any results), or what might be happening here? Ah if you're touching it anyway (I know people love when I say that - could you replace --set HYDRA_RELEASE ${version} \ with --set-default HYDRA_RELEASE ${version} \? I don't think it's worth its own PR | 16:51:14 |
| @linus.heckemann:matrix.mayflower.de | lol | 16:51:31 |
| @linus.heckemann:matrix.mayflower.de | yeah can do that | 16:51:37 |
| das_j | thanks ;) | 16:51:42 |
 Rick (Mindavi) | In reply to @linus.heckemann:matrix.mayflower.de
So I'm trying to update the hydra package in nixpkgs, and ran into migrations failing because the pgcrypto postgres extension was missing. Seems odd to me though that this wouldn't have been caught by NixOS tests. Has everyone who runs a Hydra done CREATE EXTENSION pgcrypto; manually, or am I missing a place where that's done within hydra (a plain rg pgcrypto on the hydra repo didn't yield any results), or what might be happening here? Thanks for looking into that. | 17:08:44 |
| @linus.heckemann:matrix.mayflower.de | thanks for starting the work, I picked your commit as a base :) | 17:09:00 |
| @linus.heckemann:matrix.mayflower.de | das_j: hm, why exactly should that be --set-default? Changing that to something other than the running package seems weird. | 17:14:35 |
| das_j | In reply to @linus.heckemann:matrix.mayflower.de
das_j: hm, why exactly should that be --set-default? Changing that to something other than the running package seems weird. I'm overriding the src of the package locally and the postPatch is not affected by that override | 17:15:03 |
| @linus.heckemann:matrix.mayflower.de | aah fair | 17:16:20 |
| @linus.heckemann:matrix.mayflower.de | das_j: Rick (Mindavi): would you care to be maintainers as well? With https://github.com/NixOS/nixpkgs/pull/158948 it doesn't currently have any maintainers. | 19:01:50 |
| das_j | In reply to @linus.heckemann:matrix.mayflower.de
das_j: Rick (Mindavi): would you care to be maintainers as well? With https://github.com/NixOS/nixpkgs/pull/158948 it doesn't currently have any maintainers. Yeah why not. Will probably not give me substantially more GH notifications 🤷 | 19:05:31 |
| Rick (Mindavi) | I'm running it from nixpkgs anyway, so don't mind reviewing now and then | 19:08:40 |
| @linus.heckemann:matrix.mayflower.de | sweet, so the package goes from 1 to 0 to 3 maintainers :D | 19:08:43 |
| @linus.heckemann:matrix.mayflower.de | Hm, I've been trying to mix lovesegfault's changes from https://github.com/NixOS/nixpkgs/pull/157072 in as well. Not sure if this is actually something we should do or not though | 19:27:08 |
| @linus.heckemann:matrix.mayflower.de | I think it does make sense to have a single version of hydra in nixpkgs. And I think the hydra package in nixpkgs is a bit "second-class" given that upstream development and the hno deployment use flakes. | 19:31:13 |
