This attempts to make it easier to understand and maintain our morph configurations for local, testing, and production deployments. Initially I was only trying to normalize server names so that we could document what local configuration is required to be able to manage the grids (#67 (closed) ) but I kept running into places where "simplifying" naming would actually make other things more complex so I took a break there and tried to work out the problems that were leading to that complexification.
One point of complexity that it removes is the make-grid.nix function which has several configuration values and a node-producing function passed to it. This is replaced by having each morph configuration inline the "network" that make-grid.nix created and returned. The network is actually very simple. By removing two functions (make-grid.nix and the nodes function callers were required to pass to it), I think that the code is simplified - even though there is some small increase in duplication by no longer having make-grid.nix do some of the network-definition boilerplate.
Another point of complexity that it removes is collection of functions for making a certain kind of node - issuer, storage, or monitoring. Each of these functions accepted a bundle of configuration values and returned a NixOS configuration for a single system. These functions mixed two tasks. First, they defined a lot of static (non-configurable) system configuration necessary for each system type (eg, turning on PaymentServer on the issuer node). Second, they accepted values to plug in to certain parts of the system configuration where per-system or per-grid variability was required. These functions have been replaced by two things.
First, a completely static value which defines all of the static (non-configurable) system configuration mentioned above. These are constant literal attrset values and are always the same.
Second, a function (named like customize-<type>) which accepts the minimum per-node/grid configuration necessary to finish configuring the system and puts the values into the right place. This function is not really ideal. It seems to suggest our modules are too complicated to set up (maybe they're at the wrong level of abstraction or something). It seems like a tolerable stop-gap for now though (and I better stop before this branch gets totally out of control).
A final point of complexity removed is the repetitive storage node definitions in the production grid. This is replaced by a function which knows most of what is necessary to make a storage node and only has a couple basic parameters. This can probably also be further simplified but I think that is part of the "derive the VPN and/or monitoring configuration from the node definitions" so I'm not pushing further in this direction in this branch either.