Factoring out parts of the serve protocol for Hydra to share

[Ericson2314]

Hydra uses the lock argument differently than Nix, so we un-hard-code it.

See NixOS/hydra#1165, which takes advantage of this (and #9560)

Depends on #9560

[thufschmitt]

There might be a very good reason that I’m missing, but wouldn’t it be simpler to directly use the legacy ssh store in hydra? That would also make it possible to incrementally make hydra store-agnostic by extending the store API to fit its needs

[Ericson2314]

See what I wrote in NixOS/hydra#1165 (comment) I absolutely do want to use the Store abstraction long term, but I am very concerned with accidental breakage and so want to proceed quite slowly and incrementally to avoid it.

For example, without this approach, I probably would not have noticed how hydra is using a temp GC root locking version of queryPathInfo.

Once all the serialization logic is in Nix alone, making sure the relevant Stores expose enough stuff to obviate hydra using these "raw" serialization bits directly should a safer refactor, because all the shuffling happens in one repo, and none of the serialization logic itself need be touched.

[Ericson2314]

CI is not working because recent changes broke the macOS / clang builds.

[thufschmitt]

I’ve been looking into this a bit, and I wonder whether we couldn’t do things the other way around:

1. Expose the LegacySSHStore in nix
2. Make hydra use it for the connection (essentially replacing openConnection by the LegacySSHStore constructor)
3. Gradually rewrite all the steps of the hydra build loop (the new functions from Split the buildRemote function hydra#1180) to use the store methods rather than directly writing/reading to from and to
4. Make sure that hydra doesn’t use anything that’s not a generic Store interface and hide LegacySSHStore again

(all that while expanding the implementation of the store to cover the hydra-specific edge-cases, and adding the new methods needed for the stuff like non-blocking builds).

I think that it’s essentially similar to your plan, except that hydra would directly have a full-blown store available, which would make the incremental migration easier.

Do I miss anything?

[Ericson2314]

@thufschmitt I am thinking start with #6223 and your Hydra PR, and then return to this. Sound good?

[Ericson2314]

I fixed up the Hydra part, and tests are passing just great! (At one point was wrong and tests were failing, so we know the coverage is counting for something)

I thus consider this ready --- only keeping it draft because of the first Nix PR it depends on.

[dpulls]

🎉 All dependencies have been resolved !

[Ericson2314]

team meeting notes:

• The "slow incremental migration" process is approved by the team (i.e. doing all these steps). That is on me torturing myself with many intermediate steps, shouldn't burden the team. When everything is done, and hydra isn't even using the legacy protocol any more, we should arrive at the same destination as if we did the "fast jump migration" process.

• Still blocked on @thufschmitt taking a look because his concerns from a year ago that may or may not apply.

[Ericson2314]

OK now this is rebased on top of the #9586 so we have the option of making these things part of LegacySSHStore for Hydra if @thufschmitt prefers!

[Ericson2314]

(in/after the meeting @thufschmitt said he didn't care about reviewing this one in particular.)

[roberth]

It does look equivalent. Will approve when this is tested.

[Ericson2314]

OK added some tests!