I've been noodling on the possibility of managing a bunch of Guix machines with Goblins for a little while now. Spent a little time at a local coffee shop today thinking about how this might work...

With both Guix and Goblins being written in Guile, it's at least pretty straightforward to start mashing them up:

(use-modules
 (goblins)
 (goblins actor-lib methods)
 (guix describe))

(define (^guix-machine-mgr bcom)
  (methods
   [(get-channels)
    (current-channels)]))

Of course, functions like current-channels return Guix records...

goblins/0@(guile-user) [1]> ($ mgr 'get-channels)
$6 = (#<<channel> name: guix url: "https://git.savannah.gnu.org/git/guix.git" branch: "master" commit: "5ab3c4c1e43ebb637551223791db0ea3519986e1" introduction: #<<channel-introduction> first-signed-commit: "9edb3f66fd807b096b48283debdcddccfea34bad" first-commit-signer: #vu8(187 176 45 223 44 234 246 168 13 29 230 67 162 160 109 242 163 58 84 250)> location: ((filename . "guix/channels.scm") (line . 1069) (column . 5))>)

...and I don't know yet whether these can be sent over a captp connection as-is or if I'll need to wrap them somehow. Gotta play around I guess!

One of the other things I haven't decided on yet is which parts of a Guix system exactly this should manage, since Guix lets multiple users have multiple profiles, and since the currently configured channels for a given user don't necessarily reflect the currently installed packages in the user's profile. It might make sense for such a Goblins daemon to take a specific profile as a parameter, and to essentially take ownership of that profile.

I'd also like it to be able to remotely manage the operating-system config and by extension the packages/services installed through it, though I'll need to figure out how exactly to do that. switch-to-system in (guix scripts system reconfigure) seems like it might be the right starting point.

My current (very rough) thought on what the management flow would look like is:

• On a centralized management machine, have an object per client machine that represents the desired state of that machine, with a reference to the following daemon
• On each client machine, have a daemon running that's managing the operating-system config on that machine, with a reference to the above object
• When an admin updates the list of packages/services on the machine object, it sends a message to the client daemon prompting it to run a system rebuild
• Periodically, the client daemon reaches out to the machine object to determine if it is up to date (e.g. if it's missed one of the above messages), and to fetch the current desired config if not