Custom configurations with the Machine executor

I’ve been getting comfortable with Circle at my employer recently, and decided to use it for one of my Open-Source projects, vzvol, after finding some new bugs in the program after a recent update. Until now, I’ve tested it manually, which is where the bugs managed to find a place to hide.
While initially developed for FreeBSD, I’ve since ported vzvol to function on Linux as well, so that’s no issue.
The thing is, it directly interacts with ZFS, so I can’t test it without ZFS.
A docker image can maybe sorta mount ZFS as FUSE with some host kajiggery, but that’s not how I want to roll.

I saw the Machine executor type, and have a few questions:

  1. What images can be used besides Circle’s? Ideally, a minimum of Ubuntu 16.04 is needed on my end, so I can simply kldload (or whatever the Linux equivalent is) ZFS. How would I use them? What format do they need to be in?
  2. How full is the root control? Is it a raw VM? A container taking up a whole VM? Can I create filesystems, disk images for loopback devices, load kernel modules?

TL;DR, I’d like to use a Machine executor, create a disk image, mount it as a loopback device, kldload the ZFS kernel module, install the userland tools, and then format the disk image as a zpool, for use in testing my code.

If I can do all of what I need, I’d love to use CircleCI for vzvol, and numerous other FOSS projects I’m either working on or will be working on eventually. (I really don’t want to have to set up Jenkins.)

1 Like

Great question.

So with the machine executor, there is a raw VM with full root access. We don’t support custom images from users but the executor does have a few image options.

Ubuntu 16.04+ isn’t available on the machine executor at the moment but is on the roadmap.

I’m not familiar with the things you want to run, but I wonder if you can point your Apt to a newer repository, and force install the things you need?

Failing that, compiling what you need might be an option. This would presumably be time consuming, so saving the compiled artefacts and restoring them per-build would be a good idea.

Entirely possible!
I found something “better” though :slight_smile:
The main reason I was hoping for 16.04 was because ZFS is natively supported in Ubuntu, at that point.
However, there is a PPA that allows for installation of the ZFS userland tools, and a properly compiled kmod, on 14.04.
I wouldn’t use it in production, but then again, I wouldn’t use Linux in production if I could avoid it.
However, it’s perfect for testing!
I now only wish I could bake a testing image with all these dependencies pre-installed.
It takes forever to get to the point where actual testing can be done, heh.

Interesting. I seem to recall when I looked at ZFS some years ago, that there was licensing issues that prevented ZFS from becoming a mainstream FS on Linux (and indeed why Btrfs was created instead).

:fire: :wink:

Nah. OpenZFS can’t be compiled into the Linux kernel, because Linux is GPL, and OpenZFS is CDDL.
Sadly, the GPL is rather hardline, and the only OSS license that prohibits this. FreeBSD never had a problem with including OpenZFS, which is why it’s a first-class FS on us.
As of 16.04, Ubuntu supplies an OpenZFS Linux LKM package, which doesn’t violate the terms of the GPL. KMods are fine, you just can’t compile it directly into the Linux kernel and then share that kernel binary.
My distro, Sanity Linux, is taking the same route as Ubuntu, although we’re doing our best to integrate it as tightly as legally permissable, including compiling a fresh kernel with the OpenZFS code shimmed in upon install and upgrade, if the user wishes.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.