David Thompson <dthomps...@worcester.edu> skribis: > I'm writing this in an attempt to "think out loud" about a deployment > automation tool for GuixSD.
Yay, good idea! > * The central data type is a "deployment", which is a Nix expression > consisting of one or more named OS configs > > * The OS configs contain extra data that specifies the target platform: > VirtualBox, EC2, NixOS container, etc. Each platform implements the > generic MachineDefinition and MachineState interfaces. > > * The 'nixops' command is stateful. It stores necessary state about > deployed systems in a special directory ($HOME/.nixops by default), > such as the IP addresses of the deployed systems. Because of this, > each deployment needs a unique identifier. Oh, I remember “charon create” creating this ‘network.json’ file containing the list of machines and the file names of the Nix expression used to create that deployment. I’m not 100% clear on why this state needs to be stored; it seems more like a cache to me, no? That is, Charon/NixOps can always recreate it from the source Nix expressions. > * Deployments may be parameterized by values known only at deploy time. > This covers cases such as a web application server needing to know the > IP address of the database server. > > * There are useful subcommands to check the status of each system or ssh > into one of them. > > Here's a rough outline of how I'm thinking of implementing similar > features in Guix: > > * Introduce new data types: > > * <platform>: The generic interface type for implementing deployment > targets. Its fields hold procedures for various actions like > 'provision', 'destroy', 'boot', or 'reboot'. I haven't determined > the precise list of actions needed, but it will become apparent as > platforms are added. OK. > * <machine>: Describes a single system in the deployment. Contains a > name string, an <operating-system>, and a <platform>. Yes (it’s best to keep it separate from <operating-system>; in NixOps it’s a ‘deployment’ attribute in the OS attribute set.) > * <deployment>: Contains a name string and a list of <machine> and > procedures. Procedures in the list should accept an argument > containing the deployment results of the non-parameterized machines > and return a <machine>. OK. > * Use a simple s-exp deployment state format. Store the state in > $HOME/.config/guix by default. Or ~/.cache/guix? > * Implement a 'guix ops' subcommand roughly the same actions as NixOps: > create, deploy, start, stop, destroy, list, info, check, ssh, etc. > > * The bulk of the work will be creating <platform> objects that actually > provision various types of resources. For prototyping, a > 'local-vm-platform' would be enough to test that the whole system > works. Sure. > Anyone want to join in on this brainstorming party? Your thoughts are > appreciated! It seems you already have all the requirements and design options in mind! Thanks, Ludo’.
