unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: <guix-devel@gnu.org>
Subject: Cuirass actors
Date: Wed, 13 Sep 2023 23:08:06 +0200	[thread overview]
Message-ID: <87r0n1ixxl.fsf@gnu.org> (raw)

Hello Guix!

My (useful? misguided? questionable?) quest around Cuirass has led me
closer to some of the goals mentioned in my previous message¹ and in the
‘TODO’ file².

The ‘wip-actors’ branch³, which I plan to merge soon, splits activities
of the ‘cuirass register’ process among several actors.  Quoth ‘base.scm’:

  - The "channel updater" is responsible for updating Git checkouts for
    channels.  There's a single instance of this actor; it limits
    concurrent Git updates.

  - The "evaluator" spawns evaluations of jobsets for the given channel
    instances, again limiting the number of concurrent evaluations.

  - The "builder" spawns derivation builds.  There are currently two
    implementations: the local builder sends build requests to the local
    'guix-daemon' process, while the remote build delegates builds to
    'cuirass remote-server'.

  - Each jobset as an associated "monitor"; it requests channel updates,
    evaluations, and builds to the actors above.  It also receives requests
    such as evaluation triggers that can come, for example, from the
    /jobset/NAME/hook/evaluate HTTP endpoint.

  - The "jobset" registry is a directory that maps jobset names to their
    monitor.

In addition, ‘cuirass register’ implements a “bridge”: it listens for
connections on a Unix-domain socket, which allows ‘cuirass web’ to send
it commands.

This is used for instance to implement the /jobset/NAME/hook/evaluate
HTTP endpoint, which lets users trigger an evaluation of the given
jobset.

With this actor split, one could implement another “builder” backend,
for instance one that talks to a Build Coordinator process.  It’s also
obviously close to the programming model encouraged by Goblins, which
should make eventual migration easier (and when that happens, if Goblins
provides an inter-process transport, we’ll no longer need the custom
“bridge” and we’ll be able to move actors from one process to another
much more easily.)

Feedback welcome!

Ludo’.

¹ https://lists.gnu.org/archive/html/guix-devel/2023-07/msg00096.html
² https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/tree/TODO?id=9b227abd29b15e7e25c54a71c524e7b26252a270
³ https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/log/?h=wip-actors


             reply	other threads:[~2023-09-13 21:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-13 21:08 Ludovic Courtès [this message]
2023-09-14  6:49 ` Cuirass actors Simon Tournier
2023-09-14 15:33   ` Ludovic Courtès
2023-09-14 12:50 ` Thompson, David
2023-09-14 15:31   ` Ludovic Courtès
2023-09-14 15:59     ` Thompson, David

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

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r0n1ixxl.fsf@gnu.org \
    --to=ludo@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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).