From: Richard Sent <richard@freakingpenguin.com>
To: guix-devel@gnu.org
Subject: Guix deploy --keep-going equivalent for machine connection failures
Date: Mon, 15 Jan 2024 17:47:58 -0500 [thread overview]
Message-ID: <494a6ad05644e3b4c215d2bdaf388811@freakingpenguin.com> (raw)
Hi all,
When running guix deploy with a list of machines, the command will fail
if any of the machines are unreachable. I use Guix deploy from a central
machine to update the devices on my LAN, including laptops, which aren't
guaranteed to be on. I'm also not terribly worried about keeping every
single device updated in perfect synchronicity.
I think it would be useful to have a CLI flag that would continue the
deployment even if we fail to connect to one of the machines.
At present this can be worked around by commenting out entries on the
list, but this requires
a) Already knowing what machine is offline
b) Remembering to uncomment it later when the machine goes back online
c) Generally feels "ugly" in a way that most Guix commands don't.
d) Makes version control a pain
The default behavior should stay as is, I imagine, since one of the main
uses of guix deploy is deploying an interconnected cluster of machines
that probably would not appreciate being partially upgraded.
Another option worth considered is adding a `'can-connection-fail?'
(default: #f)` to either `machine` or `machine-ssh-configuration`.
(Probably machine since it would also allow for digitalocean
deployments.) This would let me mix a list of "core machines" that I
definitely want upgraded in a deployment (NAS, etc), while still having
secondary machines that I'm not particularly concerned about upgrading.
When running a deployment, there are effectively 3 options for how I
could want the deployment to go for machines X, Y, and Z:
a) X, Y, and Z must all be deployed together <--- Supported
b) X must be deployed, but Y and/or Z can fail <---
can-connection-fail? setting
c) X, Y, and/or Z can fail <---
--keep-going-but-for-machines-I-don't-know-what-to-call-this
Anyone have thoughts on this?
Thanks,
Richard Sent
next reply other threads:[~2024-01-17 6:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-15 22:47 Richard Sent [this message]
2024-01-17 9:43 ` Guix deploy --keep-going equivalent for machine connection failures Carlo Zancanaro
2024-01-17 14:52 ` Csepp
2024-01-18 17:45 ` Attila Lendvai
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=494a6ad05644e3b4c215d2bdaf388811@freakingpenguin.com \
--to=richard@freakingpenguin.com \
--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.