Re: Guix "ops"

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

David Thompson <dthompson2@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’.