22-JUL-2024

0916

I think I’ve got a better idea on how to organize things.

A deployment of a constellation is a derivation. It’s build phase creates and caches all the cross-environment artifacts (zonefiles, images, etc), it’s install phase is a script that gathers those artifacts and deploys them to the target machines and ensures all netboot images are up to date.

elenta should provide these derivations given the constellation input, and then minas-tarwon can take those derivations and apply them to the target machines.

Two different derivations are ‘compatible’ if they do not:

  1. Overallocate any underlying machine
  2. Have contradictory configurations (i.e., colliding ports, colliding filesystem assignments/mounts, etc).
  3. Can be mkMerged with each other and still have any assertions/tests pass

Ultimately this would allow breaking down that ‘main’ derivation into, e.g., a derivation per machine or however else I want to break things up. It also makes the deployment pipeline straightforward. “Here are a bunch of constellations that elenta compiles down to a single script that you run from a provisioning machine to deploy everything specified.” Rollback is just applying the previous derivation + whatever backup restoration should be done.

Automating a pre-deploy backup can be part of the installPhase of the derivation.

Eventually it’d be cool to have the merge bit be smart and try to create, e.g., VMs and stuff dynamically, so it just becomes a ‘map machine roles to resources, don’t care about where they are hosted’

1054

I think I’m just going to leverage just in the minas-tarwon repo to port over the flying-monkey stuff. It can do the basic deployment from telperion -> machine config for now.

2317

I set up just to do deploys now, porting over flying-monkey was pretty easy, I rather like just.

Next I need to get the canon domain hosted. I just need to see how to refer to my own flake, I am pretty sure I can just pass it down as a special arg. Not sure.