Reaching out about the lxd-github-actions-runner go implementation

[rgl]

Hi @stgraber, I've started playing with a Go implementation of a LXD runner at https://github.com/rgl/lxd-github-actions-runner (aka lxd-ghar).

Its still pretty much a PoC, and I'm using it to learn about lxc/lxd; right now it can:

• Be launched as a systemd service.
  • systemd will restart the whole-sheband when the ephemeral runner terminates.
• Launch a ephemeral runner in a LXC container.
  • The runner is directly executed from lxc exec instead of a systemd service; this seems to give me more control about its execution, and its simpler to send the runner logs to stdout/stderr for easier troubleshoot.
• Use a Personal Access Token (PAT) to create the runner registration token.

I was able to use it to implement a amd64/arm64 workflow that uses Debian live-build to create a custom iso at https://github.com/rgl/tinkerbell-debian-osie/actions.

live-build uses deboostrap internally, and that seems to require me to enable lxc privileged mode and disable apparmor; since I've just started using lxc, I'm not really sure that such a privileged container is really needed, and would really appreciate your advice :-)

I would like to add the features you've mention in this repository README, like being able to maintain a pool of instances. I'm still unsure if this should be handled by systemd instead (if that is actually possible).

The current implementation is interacting with lxc/lxd by calling out the lxc process; do you think it would be better to use the https://pkg.go.dev/github.com/lxc/lxd/client library instead?

[stgraber]

Hey @rgl, sorry for the delay!

It's great to see someone picking up the idea of a proper Go daemon to handle this stuff!

I'd definitely strongly recommend using the native Go client library instead of dealing with sub-processes.

Though another thing that'd be worth noting is that long-running Exec sessions can be problematic. If LXD updates itself for one reason or another, all exec sessions will be terminated, potentially causing all those agents to disconnect or even builds to fail.

So using Exec sessions to look at what's going on in the instance or to run short lived commands is all good, LXD will in fact wait up to 5min when being updated for any such command to complete. But for long running processes, I'd strongly recommend setting up a proper systemd based service in the instance and then starting that instead.