3 ms·

This was a good read. I'm currently designing the deployment tool for GNU Guix (a package manager and distro based on Nix) so I find stories like this very val

This was a good read. I'm currently designing the deployment tool for GNU Guix (a package manager and distro based on Nix) so I find stories like this very valuable. The author didn't seem crazy about the NixOps state file, which is something I'm trying to think hard about for Guix. They claim that the state file isn't easily shareable across machines. Couldn't they just version control it and clone the repo on every workstation that does deploys or are there complications?

cwp 11y ago
It's an SQLite database, so you wouldn't be able to merge changes made in different clones.
- davexunit 11y ago
  Ah, I see. Thanks. My initial prototype will use a flat text file (a serialized s-exp) instead.
  - teh 11y ago
    Another issue is full paths to the nix config file encoded in the state file itself. The state file should not point to the config files used IMO.
    - davexunit 11y ago
      Totally agreed. The user should pass the config file to the program each time.
thoughtpolice 11y ago
There is Upcast[1], which is a different tool by Zalora and does this - it simply adds a file you can check into the repository for developers to use. It has some beta-ish limitations but the idea is what you described, basically. The remaining build step, then, is copying the new closure of the environment to the machine on deploy, which can take some time depending on your network. Instead I think what you'd probably do is use Hydra (a CI server) to actually build the packages/closure of your network on every commit to your repository, and then add that server to your actual deployment server's binary caches - that way when you deploy things after CI allows it, the needed assets will already be on the remote (faster) binary cache, within your network. [1] https://github.com/zalora/upcast https://github.com/zalora/upcast

3 ms·

This was a good read. I'm currently designing the deployment tool for GNU Guix (a package manager and distro based on Nix) so I find stories like this very val

by davexunit 11y ago

cwp 11y ago
It's an SQLite database, so you wouldn't be able to merge changes made in different clones.
- davexunit 11y ago
  Ah, I see. Thanks. My initial prototype will use a flat text file (a serialized s-exp) instead.
  - teh 11y ago
    Another issue is full paths to the nix config file encoded in the state file itself. The state file should not point to the config files used IMO.
    - davexunit 11y ago
      Totally agreed. The user should pass the config file to the program each time.
thoughtpolice 11y ago
There is Upcast[1], which is a different tool by Zalora and does this - it simply adds a file you can check into the repository for developers to use. It has some beta-ish limitations but the idea is what you described, basically. The remaining build step, then, is copying the new closure of the environment to the machine on deploy, which can take some time depending on your network. Instead I think what you'd probably do is use Hydra (a CI server) to actually build the packages/closure of your network on every commit to your repository, and then add that server to your actual deployment server's binary caches - that way when you deploy things after CI allows it, the needed assets will already be on the remote (faster) binary cache, within your network. [1] https://github.com/zalora/upcast https://github.com/zalora/upcast