[bug#36404] [PATCH 0/6] Add 'guix deploy'.

[Christopher Lemmer Webber <cwebber@dustycloud.org>]

Jakob L. Kreuze writes:

> Hello, Guix!
>
> This patch provides the basis for 'guix deploy', implementing what I've
> referred to as the "simple case" in my progress reports: in-place
> updates to machines (physical or virtual) whose name and IP address we
> know well. Do note that these commits depend on Ludovic's implementation
> of 'remote-eval'.[1]

Horray!

> #+BEGIN_SRC scheme
> ;; [...]
> (list (machine
>        (system %system)
>        (environment 'managed-host)
>        (configuration (machine-ssh-configuration
>                        (host-name "localhost")
>                        (identity "./id_rsa")
>                        (port 2222)))))
> #+END_SRC scheme
>
> The 'environment' field is where we declare how machines should be
> provisioned. In this case, the only type of provisioning that's been
> implemented is 'managed-host' -- the "simple case" of in-place updates
> to a machine that's already running GuixSD. The parameters for
> provisioning are given in the form of an environment-specific
> configuration type. In the example, this is 'machine-ssh-configuration',
> which describes how 'guix deploy' should make an SSH connection to the
> machine. I'm sure you can imagine something along the lines of a
> 'machine-digitalocean-configuration', describing some parameters for a
> droplet.

In the future I think it would be good to make this extensible as well.
Dispatching on a symbol means that Guix must itself provide a fixed set
of possible environment types.  If we made this an extensible structure,
akin to services or something, we could allow for more flexibility in
the future.  Thoughts for the future, but not a blocker on this patch.

> There are two things in this patch series that I'd like comments on in
> particular.
>
> First, I still haven't figured out the whole testing situation. The
> tests, as of now, spin up a virtual machine, create a machine instance,
> deploy that to the virtual machine, and then make assertions about
> changes made to the system. These tests were originally in the system
> test suite as they deal with virtual machines, but I've since moved it
> into the normal Guix test suite because of how much needs to be done on
> the host side -- I spent an absurd amount of time trying to fit a call
> to 'deploy-machine' into a derivation that could be run by the system
> test suite, but I just wasn't able to make it work. I'm hoping someone
> will have thoughts about how we can test 'guix deploy'. Should we have
> them disabled by default? Is there some way to implement them in the a
> system test suite that I've overlooked? Should the tests be included at
> all?

Ludo, do you have comments?  I suspect this is up your area of expertise.

> I look forward to your comments.

Yes, now for me to look at the actual patches :)