Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Deduplicate code between Hydra and Nix #1164

Open
8 of 13 tasks
Ericson2314 opened this issue Feb 20, 2022 · 8 comments
Open
8 of 13 tasks

Deduplicate code between Hydra and Nix #1164

Ericson2314 opened this issue Feb 20, 2022 · 8 comments

Comments

@Ericson2314
Copy link
Member

Ericson2314 commented Feb 20, 2022 •
edited
Loading

Currently Hydra duplicates lots of functionality that is in Nix. This is bad because it leads to either the Nix or Hydra versions of a feature being undertested and broken (e.g. remote builds are very finicky), or missing features on one side (Hydra doesn't support ssh-ng://).

The solution is to dedup, fixing both problems, and lowing our maintenance burden across the board.

I will try to break this down into steps, updating this list accordingly

Easier

Farther off

  • Duplicate Scheduling logic, Nix's build/*.cc vs Hydra

CC @rickynils @Ma27 @grahamc
@Ericson2314
Copy link
Member Author

Ericson2314 commented Feb 20, 2022 •
edited
Loading

Note to fix this, it would be very convenient to use a local build of Nix during Hydra development. I will try to hack that up.

edit it is indeed possible!

This was referenced Feb 20, 2022
Merged
Merged
Open
@Ericson2314 Ericson2314 mentioned this issue Mar 23, 2022
Merged
@Ericson2314 Ericson2314 moved this to 🏗 To discuss in Nix team Oct 31, 2022
@Ericson2314
Copy link
Member Author

https://discourse.nixos.org/t/developing-a-system-that-replaces-nix-remote-build/22388/11 lists a huge number of issues with the current remote building situation that makes using Nix in large institutional contexts difficult. CC @elaforge

The immediate goals of this issue are to shrink the amount of the code an increase testing coverage by moving us towards a world where hydra and remote building both battle-test the same code paths. But a further goal would be to, be improving the quality and flexibility of the build scheduling code, make experimentation with the alternative architectures suggested in that that thread easier.

@nixos-discourse
Copy link

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/developing-a-system-that-replaces-nix-remote-build/22388/13

@Ericson2314 Ericson2314 moved this from 🏗 To discuss to 📋 Backlog in Nix team Nov 1, 2022
@fricklerhandwerk fricklerhandwerk removed the status in Nix team Nov 21, 2022
@thufschmitt thufschmitt moved this to 🏗 To discuss in Nix team Dec 2, 2022
@nixos-discourse
Copy link

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2022-12-02-nix-team-meeting-minutes-13/23731/1

@Ericson2314 Ericson2314 changed the title Deduplicate code with Nix Deduplicate code between Hydra and Nix Feb 10, 2023
@fricklerhandwerk
Copy link
Contributor

fricklerhandwerk commented Feb 10, 2023 •
edited
Loading

Related: #1200

  • @thufschmitt: agreed with the idea, the maintenance overhead of duplicated code is significant
    • @edolstra: the big duplication is that Hydra has its own build loop, which
      • @thufschmitt: why does that exist in the first place?
      • @edolstra: for optimisation. later it was not obvious how to port it back to Nix
  • @edolstra: related: Support arbitrary stores for building #1200
  • @thufschmitt: key question: is anyone willing to spend significant time on this? sounds like months of work
    • @fricklerhandwerk: this would be a worthwhile to have funding for, because it unblocks lots of further development, such as RFC92 (dynamic derivations) and stabilising RFC62 (content-addressed derivations), separate store types
      • @Ericson2314: we also need resources for reviews, otherwise the work will never land
        • right now it ultimately revolves around trust. we could leverage different processes, such as delegating more involved reviews to pairs of team members

@nixos-discourse
Copy link

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-02-10-nix-team-meeting-minutes-31/25438/1

This was referenced Feb 16, 2023
Closed
Open
@Ericson2314 Ericson2314 mentioned this issue Mar 10, 2023
Draft
@thufschmitt thufschmitt moved this from ⚖ To discuss to ⏰ Postponed in Nix team Mar 27, 2023
@nixos-discourse
Copy link

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-03-27-nix-team-meeting-minutes-44/26759/1

@Ericson2314 Ericson2314 mentioned this issue Dec 10, 2023
Merged
@Ericson2314
Copy link
Member Author

#1340 #1339 got us a big closer on this too.

Ericson2314 added a commit that referenced this issue Jan 23, 2024
@Ericson2314
Use Nix's Machine type in a mimumal way
8200858 
This is *just* using the fields from that type, and only where the types
coincide. (There are two fields with different types, `speedFactor` most
interestingly.) No code is reused, so we can be sure that no behavior is
changed.

Once the types are reconciled on the Nix side, then we can start
carefully actually reusing code.

Progress on #1164
@Ericson2314 Ericson2314 mentioned this issue Jan 23, 2024
Merged
Ericson2314 added a commit that referenced this issue Jan 23, 2024
@Ericson2314
Use Nix's Machine type in a mimimal way
70e5469 
This is *just* using the fields from that type, and only where the types
coincide. (There are two fields with different types, `speedFactor` most
interestingly.) No code is reused, so we can be sure that no behavior is
changed.

Once the types are reconciled on the Nix side, then we can start
carefully actually reusing code.

Progress on #1164
Ericson2314 added a commit to obsidiansystems/nix that referenced this issue Jan 23, 2024
@Ericson2314
Make Machine::systemTypes a set not vector
7390327 
This is more conceptually correct (the order does not matter), and also
matches what Hydra already does.

(Nix and Hydra matching is needed for dedup
NixOS/hydra#1164)
This was referenced Jan 23, 2024
Merged
Merged
@thufschmitt thufschmitt removed this from Nix team Feb 28, 2024
Ericson2314 added a commit to obsidiansystems/nix that referenced this issue May 23, 2024
@Ericson2314
Create CommonSSHStoreConfig::createSSHMaster
8b4e3c1 
By moving `host` to the config, we can do a lot further cleanups and
dedups. This anticipates a world where we always go `StoreReference` ->
`*StoreConfig` -> `Store*` rather than skipping the middle step too.

Progress on NixOS#10766

Progress on NixOS/hydra#1164
@Ericson2314 Ericson2314 mentioned this issue May 23, 2024
Merged
Ericson2314 added a commit to obsidiansystems/nix that referenced this issue May 24, 2024
@Ericson2314
Create CommonSSHStoreConfig::createSSHMaster
140251d 
By moving `host` to the config, we can do a lot further cleanups and
dedups. This anticipates a world where we always go `StoreReference` ->
`*StoreConfig` -> `Store*` rather than skipping the middle step too.

Progress on NixOS#10766

Progress on NixOS/hydra#1164
Ericson2314 added a commit to obsidiansystems/nix that referenced this issue May 27, 2024
@Ericson2314
Create CommonSSHStoreConfig::createSSHMaster
3e9c373 
By moving `host` to the config, we can do a lot further cleanups and
dedups. This anticipates a world where we always go `StoreReference` ->
`*StoreConfig` -> `Store*` rather than skipping the middle step too.

Progress on NixOS#10766

Progress on NixOS/hydra#1164
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Ericson2314 @fricklerhandwerk @nixos-discourse