Clarify the status of NixOps

[thufschmitt]

Although NixOps used to be the de-facto tool for deploying NixOS machines, it isn't as maintained any more. Keeping it as an official project is a bit of a lie since we (the community) are barely maintaining it.

We discussed it during the Nix teams representative gathering last month, and there was a broad agreement in favour of sunsetting it one way or another.

A few solutions that were mentioned:

1. Just archive the repository, let whoever pick it up if they want to in the future
2. Move it to another place (nix-community?) if a group of people shows enough motivation for maintaining it

@K900 , @scottbot95 , @roberth : you're the only ones who contributed to it over the past year, what is your opinion on the matter?

[K900]

I've been telling people that nixops is de facto dead for ages, and there has always been some pushback to making it official. I believe @roberth has ideas on how to revive it, but no time to actually implement them, so I'll just defer to him.

[scottbot95]

I have actually stopped using NixOps in favor of terraform. While I think the concepts in NixOps are cool, I do agree it seems like it is not getting the maintenance it needs/deserves and unless the community can rally behind it we should probably look towards sunsetting the project.

[roberth]

I'm making plans and I'll get back to you ~ 20th Dec.

[roberth]

NixOps 2 has structural problems.
I have plans to resolve those, and indications are good that those can be funded. However, this funding won't include anything that facilitates a migration from NixOps 2. Hence, I've called these plans "NixOps 4".
I won't go into the details here and now, as a matter of practicality, but in a few words, it will be sustainable, more "first principles", and it will better leverage Nix.

If all goes well, anyone can get their hands on it in a couple of months from now, at which point I hope you'll be convinced that nixops4 deserves to be the new nixops, and NixOps 2 could perhaps be moved to nix-community/nixops2.

In the meanwhile, I will try to get some work done on the current NixOps 2, which is pre-release, to get it towards more of a decent release candidate, as that was part of the promise of the funded Nix deployments collective.

So my conclusion is that both projects are "in flux" and any changes we could make now would probably be invalidated soon. Moving repos has quite a significant overhead, so I'd like to avoid doing those things twice, and hence I'd prefer to revisit such decisions a couple of months from now.

unless the community can rally behind it

I will try my best to make "NixOps 4" a worthy project that the community actually wants to rally behind. I would then expect NixOps 2 to go into maintenance mode, until its users (manually?) migrate to NixOps 4. Maintenance mode might be funded from the collective (as is currently the case), but I'll be in touch with the donors, because both 2 and 4 are in scope for the collective.

The NixOps 4 project will most likely not be funded by the collective, but rather be a supporting component of another project that already has significant funding.

I'll keep you posted.

[aanderse]

@roberth amazing! 🤩

i would love to hear anything else you are able to elaborate on so please let me know where i can follow along (blogs, issues, repos, discussions, etc...) as they become available

as a hobbyist i would be very interested in hearing design decisions, etc..., with the intention of contributing as time permits

thanks for posting this! ❤️

[steve-chavez]

@roberth Excited for NixOps 4! (terraform integration?)

In the meanwhile, I will try to get some work done on the current NixOps 2, which is pre-release, to get it towards more of a decent release candidate, as that was part of the promise of the funded Nix deployments collective.

Just wanted to mention that, as top individual donor of the deployments collective ( 😮 ), I would not mind if NixOps 2 doesn't get to stable. I mean it's clear that there's no future in that. So I'd be fine if all the effort is instead focused on NixOps 4.

(Don't know how many NixOps 2 users there are, but I never transitioned from NixOps 1)

Do let me know if I can help in any way! (email at profiile)

[scottbot95]

Not sure how much time I can dedicate, but while I have migrated off NixOps in favor of terraform, I very much like the ideals of using a Nix-first deployment system. @roberth is there a place somewhere where I could read up more on the plans for NixOps 4 and/or help contribute to the planning/development of the project?

[datafoo]

Duplicate of #1545

[deepfire]

These two PRs at least fix master with the SSH backend:

• nixops: update the PrettyTable package pin to accomodate the currently available version nixpkgs#281879
• nixops_plugged: attrset of nixops builds, with varying plugin sets included nixpkgs#281883

[thufschmitt]

@roberth do you intend to start the development of NixOps 4 here?

Would you be OK with it being moved to nix-community until it is in a stage where we can actually tell people that they can fearlessly go use it?

[roberth]

@thufschmitt Moving it disrupts fetching for existing users. If it's going to be moved, I'd prefer to let that coincide with the availability of an alternative, as an opportunity to present the alternative to users.

start the development of NixOps 4 here?

I'd somewhat prefer a new repo, to start with a fresh and empty issue tracker. I'd also prefer for it to be in NixOS rather than nix-community, because I control the Hercules CI agents for NixOS, but not those of nix-community.

Draft plan:

1. create nixops4 repo
2. make it deploy NixOS to existing hardware
3. commit to forward/backward compatibility
4. create a tag nixops2_gcroot so that rev-based fetching keeps working
5. rename NixOS/nixops to NixOS/nixops2
6. rename nixops4 to NixOS/nixops, because a NixOps 5 would just be a successor of NixOps 4 in the same repo
7. when NixOps 4 has an aws provider, depending on user interest, sunset nixops2

[thufschmitt]

Moving it disrupts fetching for existing users.

At least according to Github's doc, everything should be properly redirected. So it's not really a concern

[roberth]

I've seen that not work in the past.

[jottr]

I'm just diving into nix and figured that nixops might be an interesting tool.
Nothing on the nixos wiki, the nixops documentation, or this repo indicates that this project is on hiatus/deprecated.

I've just tried to run nix-shell -p nixos in the latest nixos docker container to find that it is basically broken because it seems to depend on python 2.7.18.6 which it is refusing to evaluate.

Undocumented gotchas like these are a bit frustrating to us end users.

[hraban]

I have updated the wiki, please feel free to edit / amend etc. I'm not actually affiliated with nixops, just an interested prospective user like the rest of y'all.

[earldouglas]

@hraban Thanks for updating the wiki; it's how I found this thread and learned about NixOps 4.

At this specific time it requires some elbow grease to get running.

I still actively use NixOps 1.7 to manage a fleet of personal servers for hobby projects. In case anyone else finds it useful, here's how I install it on an otherwise up-to-date (nixos-unstable) machine:

let

  oldpkgs =
    let
      nixpkgs-src =
        builtins.fetchTarball {
          # Find latest commit at https://github.com/NixOS/nixpkgs/commits/nixos-23.05
          url = "https://github.com/NixOS/nixpkgs/archive/70bdadeb94ffc8806c0570eb5c2695ad29f0e421.tar.gz";
          sha256 = "05cbl1k193c9la9xhlz4y6y8ijpb2mkaqrab30zij6z4kqgclsrd";
        };
    in (import nixpkgs-src) {};

in {

  environment.systemPackages = [
    oldpkgs.nixops
  ];

}

[nixos-discourse]

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

https://discourse.nixos.org/t/how-can-i-install-nixops/39957/4

[aanderse]

for anyone interested in a NixOps like experience for terraform i've started hacking a little python script together here while i wait for NixOps 4

i want to emphasize that the script is little as it doesn't intend to write large high level abstractions but instead just leverage those directly from terraform... so adding new "backends" (like aws, digitalocean, or hetznercloud, for example) is quick and trivial

[Jappie3]

I would love to try & support Hetzner Cloud via a NixOps plugin, but it seems like now is not the time... has the groundwork for NixOps4 been started somewhere or is it still a plan for now?

[thufschmitt]

I've been talking with @roberth about that next week. There's no public plan yet (at least there wasn't at that time).

We agreed to have NixOps4 start in a dedicated organisation for now. I don't think it has been created yet, but it should be something like https://github.com/NixOps4

[hraban]

... you're a braver man than I am, posting a link to a username before registering it and hoping nobody will namesquat it >.>

[roberth]

I've registered it just now. That was risky.

[thufschmitt]

Ooops, I didn't even think of that 🤦‍♂️
Thanks for fixing that 😬

[nixos-discourse]

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

https://discourse.nixos.org/t/tweag-nix-dev-update-55/40996/1

[roberth]

I've created nixops4/nixops4.
It currently contains:

• Open PRs that describe where the architecture is headed
• Nix bindings for Rust
• No NixOps tool

Feel free to review the PRs, ask questions, etc. You can also use the GitHub discussions on the repo.

[nh2]

@roberth Could you clarify the scope a bit?

Will nixops4 be able to

• hard-reboot a server on Hetzner/AWS/etc
• partition a Hetzner dedicated server before installing NixOS?

If yes, how exactly does that work?

[nh2]

@roberth Could you clarify the scope a bit?

Will nixops4 be able to

• hard-reboot a server on Hetzner/AWS/etc
• partition a Hetzner dedicated server before installing NixOS?
• obtain information from the server that cannot be obtained from an API, e.g. for Hetzner, figure out the MAC address of the network interface as done in The interface detection/renaming logic is racy nixops-hetzner#48 to write a udev rule that gives that interface a stable name, so that it does not change across systemd upgrades, which would break any NixOS configuration referring to the name (which is a standard thing, e.g. networking.interfaces.enp1s0); note that this cannot be determined from the Hetzner API, and thus requires rather tight integration into the deployment tool, e.g. to SSH into the Hetzner rescue mode to list MAC addresses

If yes, how exactly does that work?

[roberth]

In general you'd tend to have at least two resources:

• the instance
• the NixOS configuration on the instance

• hard-reboot a server on Hetzner/AWS/etc

Hard-reboot is not necessarily part of the NixOps4 resource interface, but this could either be a manual nix run-like operation, and/or something that the Nix expressions for machine resources and the NixOS resource can agree on.

• partition a Hetzner dedicated server before installing NixOS?

This could be implemented in the resources that maintains the NixOS installation, or it could be a separate resource that is configured to run before the NixOS installation. In that case, it'd be a resource that consists of no-ops except for creation.
It should probably use disko to implement this functionality.

how exactly does that work?

I don't know exactly, because we'll have some freedom in terms of how NixOS integrates with NixOps. I'm sure it will evolve a bit.