[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guix "ops"
From: |
Ludovic Courtès |
Subject: |
Re: Guix "ops" |
Date: |
Thu, 30 Apr 2015 17:25:39 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
David Thompson <address@hidden> 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’.
- Guix "ops", David Thompson, 2015/04/27
- Re: Guix "ops",
Ludovic Courtès <=