Example NixOps State Backends

doc/guides/deploy-without-root.rst

@@ -61,7 +61,7 @@ the next step.
 Configuring the NixOps Network
 ******************************
 
-Edit your network.nix to specify the machine's
+Edit your nixops.nix to specify the machine's
 ``deployment.targetUser``:
 
 .. code-block:: nix

doc/manual/migrating.rst

@@ -0,0 +1,76 @@
+.. _chap-overview:
+
+Overview
+========
+
+This chapter aims to provide guidelines on migrating from NixOps 1.x to 2.0.
+
+.. _sec-layout:
+
+Code layout changes
+-------------------
+
+Using NixOps 1.0 multiple deployments spread out over the file and deployed
+from any working directory with the ``--deployment (-d)`` parameter.
+
+NixOps 2 however requires a file relative to the invocation working directory.
+It needs to be called either ``nixops.nix`` for a traditional deployment or
+``flake.nix`` for the as of yet experimental
+`flakes support <https://github.com/tweag/rfcs/blob/flakes/rfcs/0049-flakes.md>`.
+
+.. _sec-state-location:
+
+State location
+--------------
+
+In NixOps 1.0 deployment state such as provisioned resources are stored in a
+SQLite database located in ``~/.nixops``.
+
+NixOps 2 however has pluggable state backends, meaning that you will have to
+make a choice where to store this state.
+
+To implement the old behaviour of loading deployment state from the SQLite
+database located in ``~/.nixops`` add the following snippet to your deployment:
+
+::
+ {
+ network = {
+ storage.legacy = {};
+ };
+ }
+
+To implement a fire-and-forget strategy use this code snippet:
+
+::
+ {
+ network = {
+ storage.memory = {};
+ };
+ }
+
+For additional state storage strategies see the various NixOps plugins.
+
+.. _sec-state-migration:
+
+State migration
+---------------
+
+Migrating to any non-legacy backend from a previous deployment requires a
+manual migration step.
+
+#. Start by configuring the legacy backend as such::
+ {
+ network = {
+ storage.legacy = {};
+ };
+ }
+
+#. Then export the current state::
+ nixops export > state.json
+
+#. Now go ahead and configure your desired state backend.
+
+#. And finally import the old state::
+ nixops import < state.json
+
+#. Make sure to remove ``state.json`` as it may contain deployment secrets.

flake.nix

@@ -38,7 +38,9 @@
  ] ++ (builtins.attrValues linters);
 
  shellHook = ''
- export PATH=${builtins.toString ./scripts}:$PATH
+ git_root=$(${pkgs.git}/bin/git rev-parse --show-toplevel)
+ export PYTHONPATH=$git_root:$PYTHONPATH
+ export PATH=$git_root/scripts:$PATH
  '';
  };
 

nix/eval-machine-info.nix

@@ -17,6 +17,8 @@ let
  zipAttrs = set: builtins.listToAttrs (
  map (name: { inherit name; value = builtins.catAttrs name set; }) (builtins.concatMap builtins.attrNames set));
 
+ flakeExpr = (builtins.getFlake flakeUri).outputs.nixopsConfigurations.default;
+
  networks =
  let
  getNetworkFromExpr = networkExpr:
@@ -31,7 +33,7 @@ let
  in
  map ({ key }: getNetworkFromExpr key) networkExprClosure
  ++ optional (flakeUri != null)
- ((call (builtins.getFlake flakeUri).outputs.nixopsConfigurations.default) // { _file = "<${flakeUri}>"; });
+ ((call flakeExpr) // { _file = "<${flakeUri}>"; });
 
  network = zipAttrs networks;
 
@@ -260,6 +262,11 @@ in rec {
  in
  [ f ] ++ map getRequires requires;
 
+ exprToArgs = nixopsExpr: f:
+ if builtins.isFunction nixopsExpr then
+ map (a: { "${a}" = builtins.toString f; } ) (builtins.attrNames (builtins.functionArgs nixopsExpr))
+ else [];
+
  fileToArgs = f:
  let
  nixopsExpr = import f;
@@ -270,6 +277,8 @@ in rec {
 
  getNixOpsArgs = fs: lib.zipAttrs (lib.unique (lib.concatMap fileToArgs (getNixOpsExprs fs)));
 
- nixopsArguments = getNixOpsArgs networkExprs;
+ nixopsArguments =
+ if flakeUri == null then getNixOpsArgs networkExprs
+ else lib.listToAttrs (builtins.map (a: {name = a; value = [ flakeUri ];}) (lib.attrNames (builtins.functionArgs flakeExpr)));
 
 }