21-JUL-2024

1306

I was thinking about the constellation file a little more last night, and I think I prefer this design instead:

rec {
    "machine.canon.lan" = {
        hostConfig = "null | { literal, module } | import ./path/to/machine-role";
        vms = {
            "vm1" = "{ literal, module } | import";
            # ...
        };
        containers = {
            "container1" = "{ literal, module } | import";
            # ...
        };

        # arbitrary config available to be placed and used here.
    };
    "machine2.canon.wifi" = {
        # ...
    };
    # ...
}

The "machine" key is the canon name of the machine, and there are options to configure items at the host level, to spin up vms, or containers. vms and containers both take literal configurations and spin up containers/vms on the target. Additionally if these items are non-empty, it will contribute appropriate configuration to the host to support them.

Canon addresses are also extended to include protocol type, this is something I’m toying with, I’d prefer to have all interfaces bonded and then have a single logical address, but I’m not sure how good of an idea it is to bond wireless and LAN interfaces, so I’m toying with separating them at least at that level.

Unrelated, the issue I saw with toto seems to have resolved itself, so I’m guessing it was just stale DHCP leases causing trouble.

1410

One of the things I’m going to want to figure out is some mechanism to figure out when machines need to be updated to match a specific SHA within the context of a specific constellation. Ultimately I want a tool that can take a constellation and figure out how to rebuild everything to bring the constellation into compliance with the config. Not sure how to do that yet, I’m sure there is some git magic to be done, but I’m not sure what it is yet.

1645

I’m a little stuck, trying to build up to the constellation/role/machine mapping system is going to take a lot longer than I’d like, and I’m considering just manually managing the machines directly for the short term and then extracting configurations out after the fact. This will inevitably leave a big mess in the cadaster, but I think I can limit it by putting all the bespoke config in it’s own file and relying on the laurelin modules directly there.

If I do that, then I can develop all the modules, get them tested and wired up, then the constellation stuff won’t have the issue of needing to have both the modules and wireup system debugged.

I’m going to go that route, and just add a bespoke.nix into which all the stuff that ‘should’ be a machine role will go into, then later I can start to unpack that.

This also means that I can build everything around the .canon domain for now.

2132

Definitely liking the idea from earlier, I’m just placing it in the config.nix for now, but I should be able to stand up everything pretty quickly this way, I can just use a flying-monkey style script right now. I have a ton of pending changes to close in telperion and laurelin now, so I’m going to work on that tonight and then probably take some time this week to start getting the deployment pipeline working and nfs and dns working for the canon domain.