[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Guix "ops"
From: |
Ludovic Courtès |
Subject: |
Re: Guix "ops" |
Date: |
Fri, 01 May 2015 16:48:57 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
David Thompson <address@hidden> skribis:
> 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.
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’.
- Re: Guix "ops",
Ludovic Courtès <=