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)));
 
 }