David Thompson <dthomps...@worcester.edu> skribis: > 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.
Hmm, I see. > 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. I agree. There must be a way to at least to a one-way mapping from the <machine> object to the corresponding key in the cache. >>> * <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? What about simply ignoring them? ‘guix system vm’ ignores the bootloader, for instance, unless it is passed --full-boot. > 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. Sounds good to me. The thing that needs more thought is how to handle things like networking. I guess the tool would need to automatically add, say, a ‘dhcp-client-service’ to each <operating-system> object, and to remove existing services that provide ‘networking’, and probably fiddle with other parameters such as the initrd and file systems. (Similar to what ‘virtualized-operating-system’ does in (gnu system vm).) In effect, one would not be deploying the exact OS that is specified, but rather a variant automatically customized for the deployment target. So probably each <deployment> object must specified an <operating-system> -> <operating-system> procedure that does this transformation. WDYT? BTW, I’d prefer something like ‘guix deploy’ over ‘guix ops’, but then another name would need to be found for the ‘deploy’ sub-command, maybe ‘realize’? Thanks, Ludo’.