Re: Guix "ops"

[David Thompson]

Ludovic Courtès <address@hidden> writes:

> David Thompson <address@hidden> 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