Re: Guix "ops"

[ludo@gnu.org (Ludovic Courtès)]

David Thompson <dthompson2@worcester.edu> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> David Thompson <dthompson2@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’.