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).

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 are 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).

In reply to @whentze:matrix.org
we built something like that at work, kinda

here's another question occupying my mind as I'm thinking about the structure for a new hive.

From reading past conversations in this channel it seems that one can define a host in (at least) 3 different ways

1. with colmena + a wrapper to wire the host configuration into nixOsConfiguration
2. with nixosConfiguration + some wrapper to make the host config colmena compatible
3. outside of either colmena or nixosConfiguration with 2 wrappers to make the host config compatible (as demonstrated in Yureka (she/her) suxin code)
   After seeing code for each possibility I struggle to understand what are the down/ up sides of them in order to help me make the right decision.

As I'm guessing there's no "decision chart" available 😉 Could y'all help me to figure out what the pros/ cons/ limitations for the approaches are?

In reply to @dantefromhell:matrix.org
sweet! Is any of the work publicly available for inspiration?