I’ve been playing with nixops and a few successes just deploying to virtual box locally.
I want to see if i could deploy something older or newer than my current system version using the virtualbox backend.
Seems nixops depends on nixpkgs, when it deploys…
. I know there is a lot of nixos magic going on , so it makes sense… if deploying over ssh to a real machine your probably not going to get this problem, as there not dependency on itself or any system components to provision the machine.
To provision the ‘machine’, nixops talks to virtual box manager, if these are out of version sync, then it won’t be able to provision the machine. like so.
has some good idea’s there , i can pin my nixops at any version i want, but this still come against the vbox mismatch.
setting nix.nixpkgs seem like another solution, but if i set it , nixops can provision the virtualbox image , but it than has trouble ssh connecting to the deployed image.
So, i don’t think there’s anyway around this. I got a strong feeling when the machine your deploying to is decoupled from the machine your deploying from these problems go away. Maybe this is why vbox targets have been removed from nixops 2.0?
then i discover a post that you can use nixops to deploy from local to localhost, over ssh? Then my mind was truly blown…
am i on the right track or am i fundamentally misunderstanding the nixops workflow?
I think this is a because nixops needs to provision a virtualbox machine, but the provisioning API/Service has to match the virtuallbox running on the system. Setting nixops to higher version breaks this. There seems to be no way to decouple nixops from the actually build version… this is probably by design.
nixops over ssh without provisioning, is probably going to be a lot easier as the nixops and the provisioning code doesn’t have to be lockstep. it just needs a working ssh connection.