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?