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.

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

Feature wishlist and general orientation of this tool #2

Open
infinisil opened this issue Jan 13, 2020 · 3 comments
Open

Feature wishlist and general orientation of this tool #2

infinisil opened this issue Jan 13, 2020 · 3 comments

Comments

@infinisil
Copy link
Owner

No description provided.

@infinisil
Copy link
Owner Author

infinisil commented Jan 13, 2020

@infinisil
Copy link
Owner Author

infinisil commented Sep 24, 2020

In #nixus, @ashkitten was wondering about bootstrapping a system (logs). A possibility I thought of:

  • Have a NixOS option like system.bootstrap = true, which would turn off all non-essential system config, only leaving things like networking, hardware, filesystems, etc.
  • This will make the build cheap, useful for installer images, where nixos-install can be used to install such a bootstrap system
  • Potentially the .drv closure of the full system could also be installed with nixos-install, such that on first boot, the system can start building that and switch to it automagically.

@infinisil
Copy link
Owner Author

infinisil commented Sep 24, 2020

In #nixos-chat @andir was talking about wanting to have machines configs depend on IP's yet to be provisioned, and related things (logs). After thinking about this, I came up with the following idea that generalizes this concept well:

  • We split the global deployment script into a number of phases
  • Phases can specify a single executable, which can do mutable things, and output a JSON on stdout
  • A phase can use another phases output by specifying it as a dependency. This will cause the deployment to first do a Nix evaluation only with the phases that don't have any dependencies and collecting their outputs. After that, another evaluation is done, this time including all the collected outputs. Repeat until all phases are done
  • Phases should be able to have their outputs be persisted. This could be done by them specifying a json file to persist the output to.

This could look like this:

{ pkgs, ... }: {
  phases.provision = {}: {
    executable = pkgs.writeScript "provision" ''
      ip=$(curl https://my.provider/provision)
      echo "{ \"ip\" : $ip }"
    '';
    # If this file exists, its value will be used as the phase output
    # If it doesn't exist, the output is written there on phase call
    persistTo = ./provision.json;
  };
  # The deploy phase depends on the provision phases output, which will be
  # passed to this function
  phases.deploy = { provision }: {
    executable = pkgs.writeScript "deploy" ''
      nix-copy-closure --to ${provision.ip} ${<system-closure>}
      ssh ${provision.ip} ${<system-closure>}/bin/switch-to-configuration switch
    '';
  };
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant