Ludovic Courtès <l...@gnu.org> writes: > David Thompson <dthomps...@worcester.edu> skribis: > >> * 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.
The state that I am concerned with are the details of the resources that have been provisioned by 'guix ops'. For example, in a system that provisions VMs on behalf of the user, the IP address of the machine isn't known until the provisioning has happened. This detail needs to be saved so that 'guix ops' knows how to perform future operations on the machine. Caching the file names of the expressions with a unique key seems hacky to me, and I don't want to copy that without good reason. >> * <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.) Yes, though I do have a question here. Some platforms don't do anything with a bootloader, or in the case of containers (looking towards the future here) the 'kernel' field will be benign as the system shares the kernel of its host. I'm not sure how to deal with this extraneous information. In the case of the 'bootloader', it currently must be specified, so the user would have to input bootloader details that are irrelevant. Thoughts? >> * Use a simple s-exp deployment state format. Store the state in >> $HOME/.config/guix by default. > > Or ~/.cache/guix? Sure, that makes more sense. >> 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, but things are still a bit fuzzy so any design other design considerations are much appreciated. :) So far, I have created the barebones 'guix ops' subcommand and defined the new data types. One can run 'guix ops build deployment.scm' to build all of the machines in a deployment, but no other subcommands have been implemented. For the prototype, I envision 'guix ops deploy local-vm-deployment.scm' to work much like 'guix system vm system.scm', except that it builds and boots multiple VMs. -- David Thompson Web Developer - Free Software Foundation - http://fsf.org GPG Key: 0FF1D807 Support the FSF: https://fsf.org/donate
