7-AUG-2024

(and a bit of 6-AUG too)

0141

I’m doing something wrong with the filesystem definitions, I need to rebuild the pool again.

I got the script using wwns to make sure it persists, but that wasn’t why the thing was breaking on boot, to be honest, I’m not sure why it’s breaking on boot, but I think I might be able to skirt all of this because of this, but that needs a rebuild.

1142

I’ve got it mostly working with the automount, but I’d still like to understand what I was doing wrong w/ the filesystem definitions; probably I needed to set different options or something, the emergency shell never managed to start, so it’s hard to figure out exactly what went wrong.

In any case, I like the way I laid out the disks and want to extend the idea of the cadaster in that way, building a large nixos-style module system that describes all my hardware (and maybe integrates with the nascent nixos facter tool) and then can be used to populate other parts of the configuration by reference seems pretty handy.

Ultimately I think it also points at a way out of the nix ecosystem while still maintaining the ‘single common configuration system’ that I like about NixOS. There’s no reason to couple it to Nix besides the convenience of the package manager, a declarative description of one’s hardware and virtual hardware architecture is useful in it’s own right and could ostensibly be compiled to instructions to configure virtually anything from a known starting state. My interest in it is actually simpler, to boot, I just want to be able to simulate arbitrary architectures and employ some kind of static analysis to surface issues at ‘compile time’; I think getting anywhere near that for architecture design could be extremely valuable.

1532

I’m going to do some tweaking to the cadaster idea, I’m going to split it between narya and telperion, two items with the same underlying schema, both provided as flake outputs, telperion will pull in and merge narya’s definitions into it’s own at build time, but will otherwise be unaware, that structure will then be available to all subsequent definitions. I’ll probably just keep the hardware defs in telperion for now, but they may be extracted to laurelin later if that seems prudent.

The structure will be something like:

{
    compute = {
        "hostname" = {
            # metadata
        };
        # ...
    };
    storage = {
        disks = {
            "diskname" = {
                # metadata
                # includes a reference to `cadaster.compute.hostname` for where it's installed
            };
            # ...
        };
    };
    network = {
        switches = {
            "switchname" = {
                # metadata
                # Should include port maps and the like.
            };
            # ...
        };
        routers = {
            "routername" = {
                # metadata
            };
            # ...
        };
        firewalls = {
            "firewallname" = {
                # metadata
            };
            # ...
        };
    };
    racks = {

    };
    power = {

    };
    # ...
}

The idea is to represent each physical item in this with all it’s metadata, but none of it’s configuration. Configuration then consumes this to build the actual configuration, and the resulting configuration is then used to build the actual system images.

Essentially it’s DCIM-as-code. I’m sure this has been done before, but reinventing wheels is fun.

I’m going to build each chunk as nixos modules, and then I can use that to attach additional computed information to each section. Ideally I can use this to drive some sort of testing/monitoring tools as well.