From: ludo@gnu.org (Ludovic Courtès)
To: Christopher Allan Webber <cwebber@dustycloud.org>
Cc: guix-devel@gnu.org, David Thompson <davet@gnu.org>
Subject: Re: Guix "ops"
Date: Thu, 20 Oct 2016 21:41:45 +0200 [thread overview]
Message-ID: <87shrqzu2u.fsf@gnu.org> (raw)
In-Reply-To: <87oa2feyzz.fsf@dustycloud.org> (Christopher Allan Webber's message of "Thu, 20 Oct 2016 12:01:04 -0500")
Christopher Allan Webber <cwebber@dustycloud.org> skribis:
> Ludovic Courtès writes:
>
>> Christopher Allan Webber <cwebber@dustycloud.org> skribis:
>>
>>> - Should I build the entire derivation of the system I want to run on
>>> the remote machine locally first, then copy that over? (I assume
>>> this is possible, and eventually desirable, especially if doing
>>> mass deployments? But it might not be desirable in every case.)
>>> Would that use the substitute mechanism?
>>
>> Yes! :-)
>>
>> Essentially deployment would work like this:
>>
>> 1. Compute the system derivation and build it locally (i.e., on the
>> machine where ‘guix deploy’ is running.)
>>
>> As a user, you can choose to have offloading setup such that the
>> actual build will take place on (some of) the target machines, but
>> that’s completely orthogonal.
>>
>> 2. Send the derivation out to the target(s) that are real machines.
>> For targets that are local containers or VMs, there’s nothing to
>> do.
>>
>> 3. On targets that are real machines, perform the equivalent of ‘guix
>> system reconfigure’—i.e., update the /run/current-system symlink,
>> restart Shepherd services that can be restarted, etc.
>>
>> IIRC David was testing using VMs and containers as the targets (the
>> <platform> record¹) because it’s easier.
>>
>> Does that make sense?
>>
>> Hopefully David will correct me. :-)
>
> Ok, it does make sense!
>
> It's nice to see the examples in the docs of exporting a system over
> ssh, even. Anyway, I played with "guix archive" this morning; it works
> well. So, sending an entire closure over the network: should be easy.
>
> I see that there's a --missing field; I'm a little bit unsure of how two
> machines would coordinate here though with the existing tooling... it
> doesn't look like we have a way to export the list of packges that
> --missing could then read in? And then you'd need to feed whatever
> --missing gave you back into --export I guess.
Yes, there’s an example of that in (guix scripts offload), in
‘send-files’.
Essentially you do:
guix archive --export \
`guix gc -R the-thing-to-send | ssh host guix archive --missing` | \
ssh host guix archive --import
HTH!
Ludo’.
next prev parent reply other threads:[~2016-10-20 19:41 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-27 23:38 Guix "ops" David Thompson
2015-04-30 15:25 ` Ludovic Courtès
2015-04-30 16:53 ` David Thompson
2015-05-01 14:48 ` Ludovic Courtès
2015-05-04 23:51 ` Carlos Sosa
2015-05-05 2:00 ` David Thompson
2015-05-05 7:57 ` Ludovic Courtès
2015-05-07 3:02 ` Christopher Allan Webber
2015-05-22 14:59 ` David Thompson
2015-05-22 16:06 ` Ludovic Courtès
2015-05-22 16:24 ` David Thompson
2015-05-27 18:47 ` Carlos Sosa
2015-05-28 16:10 ` Thompson, David
2015-05-27 19:41 ` Ludovic Courtès
2015-05-28 16:13 ` Thompson, David
2015-07-09 18:27 ` OpenStack and GuixOps (was: Re: Guix "ops") Christopher Allan Webber
2015-07-10 2:18 ` Ian Denhardt
2015-07-10 17:24 ` OpenStack and GuixOps Ludovic Courtès
2015-06-01 15:18 ` Guix "ops" Pjotr Prins
2015-06-01 16:49 ` Thompson, David
2015-06-01 19:35 ` Guix deploy (and replace Puppet/Chef) Pjotr Prins
2015-07-10 16:37 ` Guix "ops" Christopher Allan Webber
2016-10-16 23:36 ` Christopher Allan Webber
2016-10-17 14:51 ` Ludovic Courtès
2016-10-19 21:10 ` Christopher Allan Webber
2016-10-20 13:29 ` Ludovic Courtès
2016-10-20 17:01 ` Christopher Allan Webber
2016-10-20 19:41 ` Ludovic Courtès [this message]
2019-02-11 13:31 ` It's time to build "guix deploy" Christopher Lemmer Webber
2019-02-11 14:02 ` Pjotr Prins
2019-02-11 14:47 ` Christopher Lemmer Webber
2019-02-11 18:11 ` Amirouche Boubekki
2019-02-11 14:57 ` Christopher Lemmer Webber
2019-02-11 15:25 ` Pjotr Prins
2019-02-11 16:58 ` Thompson, David
2019-02-11 20:49 ` Ricardo Wurmus
2019-02-13 19:04 ` Giovanni Biscuolo
2019-02-14 7:14 ` swedebugia
2019-02-14 8:17 ` Pjotr Prins
2019-02-14 15:35 ` Giovanni Biscuolo
2019-02-14 16:55 ` Pjotr Prins
2019-02-14 14:17 ` Giovanni Biscuolo
2019-02-17 8:41 ` swedebugia
2019-02-17 15:42 ` Giovanni Biscuolo
2019-02-12 13:34 ` Christopher Lemmer Webber
2019-02-12 14:53 ` Thompson, David
2019-03-09 23:29 ` building " Thompson, David
2019-03-10 17:42 ` Ludovic Courtès
2019-03-11 14:41 ` Christopher Lemmer Webber
2019-03-12 13:08 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87shrqzu2u.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=cwebber@dustycloud.org \
--cc=davet@gnu.org \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.