I'm using the colmena from git (commit 9db25bd) with flakes.

I'm struggling to understand how to define a hive w/ 2 systems where one is using nixpkgs/22.05 while the other is using nixpkgs/unstable as pkgs source.

      meta = {
        nixpkgs = import nixpkgs { system = "x86_64-linux"; };
        nodeNixpkgs = {
          rpi-tv = import nixpkgs-unstable {};
        };
...      
}```

In reply to @janejasperous:one.ems.host

      meta = {
        nixpkgs = import nixpkgs { system = "x86_64-linux"; };
        nodeNixpkgs = {
          rpi-tv = import nixpkgs-unstable {};
        };
...      
}```

Until I change the system in nodeNixpkgs to something different than nixpkgs. Than I get the error

[ERROR]   stderr) error: a 'aarch64-linux' with features {} is required to build '/nix/store/h5ggpshqjbl14pp1qri043d5dk0n2iyc-append-initrd-secrets.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}

In reply to @dantefromhell:matrix.org

Until I change the system in nodeNixpkgs to something different than nixpkgs. Than I get the error

[ERROR]   stderr) error: a 'aarch64-linux' with features {} is required to build '/nix/store/h5ggpshqjbl14pp1qri043d5dk0n2iyc-append-initrd-secrets.drv', but I am a 'x86_64-linux' with features {benchmark, big-parallel, kvm, nixos-test}

In reply to @schnecfk:ruhr-uni-bochum.de
Either use deploy.buildOnTarget, enable qemu binfmt emulation or try and get it running using pkgsCross for true cross compilation

Thx, worked.

For anyone interested, my solution was to add

boot.binfmt.emulatedSystems = [ "aarch64-linux" ];

to configuration.nix on the machine that I run colmena build on

In reply to @dantefromhell:matrix.org

Thx, worked.

For anyone interested, my solution was to add

boot.binfmt.emulatedSystems = [ "aarch64-linux" ];

to configuration.nix on the machine that I run colmena build on

In reply to @huyage:matrix.org
Colmena is working well for me after I had trouble using nixops. I'm just curious: why are there so many nix-based deployment/config management tools? AFAIK nixops is the OG one. (I understand Colmena doesn't provision resource like nixops) Is there some history here?

In reply to @huyage:matrix.org
Colmena is working well for me after I had trouble using nixops. I'm just curious: why are there so many nix-based deployment/config management tools? AFAIK nixops is the OG one. (I understand Colmena doesn't provision resource like nixops) Is there some history here?

To add on the answer by Buckley (Which answers why so many alternatives to NixOps appeared), it's also because it's somewhat easy to build such a tool based on nix.

Being a bit handwavy here, but it generally boils down to some combination of nix-build and nix-copy-closure. I've also seen some messages of people doing these steps with a shell script instead of any deployment tool.
This "foundation" is really clear if you've switched the deployment tool (e.g. from nixops to colmena) - you don't have to change that much to get it working, especially in comparison to switching between puppet, ansible or similar tools (or even the initial nix migration).

The deployment tools nonetheless offer a big plus, the more obvious ones would be secret management and the generally better user experience.

In reply to @janejasperous:one.ems.host
nixops is maybe more in terraform league

In reply to @schnecfk:ruhr-uni-bochum.de

To add on the answer by Buckley (Which answers why so many alternatives to NixOps appeared), it's also because it's somewhat easy to build such a tool based on nix.

Being a bit handwavy here, but it generally boils down to some combination of nix-build and nix-copy-closure. I've also seen some messages of people doing these steps with a shell script instead of any deployment tool.
This "foundation" is really clear if you've switched the deployment tool (e.g. from nixops to colmena) - you don't have to change that much to get it working, especially in comparison to switching between puppet, ansible or similar tools (or even the initial nix migration).

The deployment tools nonetheless offer a big plus, the more obvious ones would be secret management and the generally better user experience.

In reply to @dantefromhell:matrix.org
I was reading on github a bit about bootstrapping w/ colmena and the general answer was "no - because it requires state tracking".

I was pondering if the approach to introduce a `colmena bootstrap` action to isolate bootstrapping from applying would remove the need for tracking state?

In reply to @dantefromhell:matrix.org
I was reading on github a bit about bootstrapping w/ colmena and the general answer was "no - because it requires state tracking".

I was pondering if the approach to introduce a `colmena bootstrap` action to isolate bootstrapping from applying would remove the need for tracking state?

In reply to @schnecfk:ruhr-uni-bochum.de
I'm not really helpful here, but just for clarification: Are you referring to these Issues? https://github.com/zhaofengli/colmena/issues/42 and https://github.com/zhaofengli/colmena/issues/68

In reply to @dantefromhell:matrix.org
I was reading on github a bit about bootstrapping w/ colmena and the general answer was "no - because it requires state tracking".

I was pondering if the approach to introduce a `colmena bootstrap` action to isolate bootstrapping from applying would remove the need for tracking state?

In reply to @dantefromhell:matrix.org
I was reading on github a bit about bootstrapping w/ colmena and the general answer was "no - because it requires state tracking".

I was pondering if the approach to introduce a `colmena bootstrap` action to isolate bootstrapping from applying would remove the need for tracking state?