Cuirass actors

Cuirass actors

[Ludovic Courtès]

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

Re: Cuirass actors

[Simon Tournier]

Hi,

It is really cool! :-)

On Wed, 13 Sep 2023 at 23:08, Ludovic Courtès <ludo@gnu.org> wrote:

>   - 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'.

[...]

> With this actor split, one could implement another “builder” backend,
> for instance one that talks to a Build Coordinator process.

IIUC, the current two “builder” backend are:

 + local ’guix-daemon’: the queue of derivations is processed using one
   strategy – the one implemented in C++,

 + ’cuirass remote-server’: the queue of derivations is processed using
   another strategy – implemented in Guile relying on ZeroMQ (something
   like steal of work, if I remember correctly).

Is it correct?

The Build Coordinator also implements the other actors “channel
updater”, “evaluator”, etc., right?  From my rough understanding, the
first aim of Build Coordinator is the implementation of the “builder”.
Is it correct?

My two questions are:

 1. Is the Build Coordinator able to only process the queue of
    derivations?  (being a “builder” backend).  And if yes, what is its
    strategy for processing?

 2. In this picture of actor model, would it make sense (or would it be
    possible) to replace the “builder” actor from the Cuirass one to the
    Build Coordinator one?

Cheers,
simon

     

Re: Cuirass actors

[Ludovic Courtès]

Simon Tournier <zimon.toutoune@gmail.com> skribis:

> IIUC, the current two “builder” backend are:
>
>  + local ’guix-daemon’: the queue of derivations is processed using one
>    strategy – the one implemented in C++,
>
>  + ’cuirass remote-server’: the queue of derivations is processed using
>    another strategy – implemented in Guile relying on ZeroMQ (something
>    like steal of work, if I remember correctly).
>
> Is it correct?

Yes.

> The Build Coordinator also implements the other actors “channel
> updater”, “evaluator”, etc., right?

No.

> From my rough understanding, the first aim of Build Coordinator is the
> implementation of the “builder”.  Is it correct?

Yes.

> My two questions are:
>
>  1. Is the Build Coordinator able to only process the queue of
>     derivations?  (being a “builder” backend).  And if yes, what is its
>     strategy for processing?

Yes, you give it derivations and it builds them; as for what its
scheduling strategy is, I don’t know!

>  2. In this picture of actor model, would it make sense (or would it be
>     possible) to replace the “builder” actor from the Cuirass one to the
>     Build Coordinator one?

Yes, that’s exactly the message I tried to convey.  :-)

Thanks,
Ludo’.

Re: Cuirass actors

[Thompson, David]

Hey Ludo,

On Wed, Sep 13, 2023 at 5:08 PM Ludovic Courtès <ludo@gnu.org> wrote:
>
> 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.)

We're obviously very excited by this development over at Spritely. :)

I'm curious to hear more about your inter-process transport needs!

- Dave

Re: Cuirass actors

[Ludovic Courtès]

Hi!

"Thompson, David" <dthompson2@worcester.edu> skribis:

> I'm curious to hear more about your inter-process transport needs!

I’d like to have actors running in separate processes on the same
machine.  I wouldn’t want them to communicate over Tor or TCP+TLS;
rather, I’d like them to use AF_UNIX sockets, “abstract sockets”, pipes,
socketpairs—one of these local IPC mechanisms.

My understanding is that there could be an ocapn “netlayer” based on
that.  Does that make sense?  Is this something you’re considering?

Thanks,
Ludo’.

Re: Cuirass actors

[Thompson, David]

On Thu, Sep 14, 2023 at 11:31 AM Ludovic Courtès <ludo@gnu.org> wrote:
>
> Hi!
>
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
> > I'm curious to hear more about your inter-process transport needs!
>
> I’d like to have actors running in separate processes on the same
> machine.  I wouldn’t want them to communicate over Tor or TCP+TLS;
> rather, I’d like them to use AF_UNIX sockets, “abstract sockets”, pipes,
> socketpairs—one of these local IPC mechanisms.
>
> My understanding is that there could be an ocapn “netlayer” based on
> that.  Does that make sense?  Is this something you’re considering?

Thanks for clarifying! Yes, we definitely intend to provide local IPC
netlayers such as UNIX domain sockets.  We actually have a test
netlayer that uses UNIX domain sockets, so some of this work has
already been done.

- Dave