I was wondering if tags could be used to map nixpkgs overrides?

I do like the idea of each machines definition being fully contained within a single file/ directory. Needing to do per-machine meta.nodeNixpkgs feels "unclean".
I would rather prefer to use tags for grouping different machines together and than override the specific nixpkgs for this tag.

Is that possibly as of today?

In reply to @dantefromhell:matrix.org

I was wondering if tags could be used to map nixpkgs overrides?

I do like the idea of each machines definition being fully contained within a single file/ directory. Needing to do per-machine meta.nodeNixpkgs feels "unclean".
I would rather prefer to use tags for grouping different machines together and than override the specific nixpkgs for this tag.

Is that possibly as of today?

In reply to @rendakuenthusiast:imperishable.name
what's the correct way to pin the nixpkgs version when using colmena with a flake?

In reply to @me:indeednotjames.com
can you elaborate?
you should have an auto-generated flake.lock

In reply to @me:indeednotjames.com
You might want to follow https://github.com/zhaofengli/colmena/issues/55 and https://github.com/zhaofengli/colmena/issues/71

In reply to @rendakuenthusiast:imperishable.name
I would like to replicate this with a flake.nix setup, but I am not sure how to do that from the documentation at https://colmena.cli.rs/unstable/tutorial/flakes.html

oicic
you might want to read up some generic flake tutorials

an extremely brief introduction would be that inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable" you can see in the example you linked to sets the nixpkgs of your nodes to the nixos-unstable branch.
when you run colmena the first time with a flake.nix, nix will automatically create a flake.lock, containing a rev of a commit of that branch from github.com/NixOS/nixpkgs

you can use any branch you like, e.g. nixos-22.11 or nixos-22.11-small

to update the rev in the flake.lock, you can use nix flake update

In reply to @me:indeednotjames.com

oicic
you might want to read up some generic flake tutorials

an extremely brief introduction would be that inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable" you can see in the example you linked to sets the nixpkgs of your nodes to the nixos-unstable branch.
when you run colmena the first time with a flake.nix, nix will automatically create a flake.lock, containing a rev of a commit of that branch from github.com/NixOS/nixpkgs

you can use any branch you like, e.g. nixos-22.11 or nixos-22.11-small

to update the rev in the flake.lock, you can use nix flake update

In reply to @zhaofeng:zhaofeng.li
Good idea! We can add aliases, and the whole config will be generated as a string by eval.nix

In reply to @me:indeednotjames.com
You might want to follow https://github.com/zhaofengli/colmena/issues/55 and https://github.com/zhaofengli/colmena/issues/71

Thinking through this more, just moving the nodeNixpkgs option is not the only goal.

One process I was hoping the tag idea allows to build is answering queries like:

Which hosts require an apply after submitting a patch/ security fix/ bugfix to one of the source repos?

In reply to @dantefromhell:matrix.org

Thinking through this more, just moving the nodeNixpkgs option is not the only goal.

One process I was hoping the tag idea allows to build is answering queries like:

Which hosts require an apply after submitting a patch/ security fix/ bugfix to one of the source repos?

Which hosts require an apply after submitting a patch/ security fix/ bugfix to one of the source repos?

you could probably also just colmena build all nodes and check which nodes produce a different outpath and then only apply those

In reply to @rendakuenthusiast:imperishable.name
is there a way to set the rev to an explicit value from the beginning, like I'm doing with the non-flake version?

In reply to @me:indeednotjames.com

Which hosts require an apply after submitting a patch/ security fix/ bugfix to one of the source repos?

you could probably also just colmena build all nodes and check which nodes produce a different outpath and then only apply those

building to verify feels wrong in an environment where all inputs (config & packages) is managed declaratively.

the list of affected hosts should be queryable - e.g. within a CI/CD pipeline because we have all the inventory information available

In reply to @dantefromhell:matrix.org

building to verify feels wrong in an environment where all inputs (config & packages) is managed declaratively.

the list of affected hosts should be queryable - e.g. within a CI/CD pipeline because we have all the inventory information available

I am confused.
colmena is stateless by design. and to know which nodes need to updated, you would have to keep track of the nodes closures/generations.

you can probably use a pre-apply hook, to fetch the current system generation and compare it with your locally build one (you are trying to apply) and stop if they are already the same or whatever.
are you thinking of something like that?

In reply to @me:indeednotjames.com

Which hosts require an apply after submitting a patch/ security fix/ bugfix to one of the source repos?

you could probably also just colmena build all nodes and check which nodes produce a different outpath and then only apply those

building to verify feels wrong in an environment where all inputs (config & packages) are managed declaratively.

the list of affected hosts should be queryable - e.g. within a CI/CD pipeline because we have all the inventory information available

Emily:

colmena is stateless by design. and to know which nodes need to updated, you would have to keep track of the nodes closures/generations.

I disagree. For 1 commit this query should always be doable without contacting any host because the desired inventory state is declared.

The situation I can think of where you need to check the deployed closures is if you are trying to solve "configuration drift" and deployment of patches with a single solution - which is kinda the common pattern in non-declarative environments.

But if you're looking at config drift (which I'm still wondering if that can actually be a reasonable thing within NixOS given the generations mechanism 🤔) and the "affected query" as 2 separate problems the aforementioned query actually becomes independent of colmena itself (and therefore the stateless limitation).

Emily:

colmena is stateless by design. and to know which nodes need to updated, you would have to keep track of the nodes closures/generations.

I disagree. For 1 commit this query should always be doable without contacting a host because the old & new desired state is clearly defined.

The situation I can think of where you need to check the deployed closures is if you are trying to solve "configuration drift" and deployment of patches with a single solution - which is kinda the common pattern in non-declarative environments.

But if you're looking at config drift (which I'm still wondering if that can actually be a reasonable thing within NixOS given the generations mechanism 🤔) and the "affected query" as 2 separate problems the aforementioned query actually becomes independent of colmena itself (and therefore the stateless limitation).