November was a productive month for us. As you’ve already glimpsed in the KDE snaps article, we hosted a Snapcraft Summit in our London offices, during which we worked with engineers from major companies on building snaps. Hailing from Intel, Julio Montes joined us to improve the Kata Containers snap, to make it easier for community members to participate and contribute to the project. Kata Containers is a new open source project building extremely lightweight virtual machines that seamlessly plug into the containers ecosystem. So what have we done?

Development … in four dimensions

The Kata Containers project is rather interesting and unique in how the development and integration is done. It comes with a complex mix of target platforms and software versions for those platforms, resulting in a multi-dimensions build matrix (using Jenkins).

Originally, Kata Containers were distributed using a third-party repository, but the dependencies posed a problem. The developers had to identify the dependencies and then include them in the ‘recipe’ for the build, but then also make sure those packages worked across multiple distributions. Since the naming convention of packages was different in each distribution, this was a rather time-consuming process. Snaps help resolve this issue, including a simplified build integration.

However, even with snaps, there was still a level of complexity in the build environment. Prior to the summit, the Kata team would use several scripts to create snapcraft.yaml files with the relevant software versions for the specific target architecture. Julio wanted a simplified workflow, which would be easier to maintain. We helped Julio flatten the current flow that uses multiple scripts into a single compact snapcraft.yaml file that automatically detects and declares the relevant software versions for each target platform, We did this using the override-pull and override-build declarations.

Override-pull is a useful directive to change the software download process. Multi-architecture projects might face problems with the version of a build dependency. For example version X is needed on x86_64, while on arm64, version Y is used. To deal with these use cases, the override-pull directive can be used to change the way dependencies are downloaded. The code snippet below is used to get a specific version of Golang depending of the system architecture.

parts:
   go:
     override-pull:
       git clone https://github.com/golang/go .
       case "$(arch)" in
         "x86_64")
           git checkout go1.11.2
         ;;
    "ppc64le")
      git checkout go1.10.1
    ;;

    "aarch64")
      git checkout go1.10.5
    ;;

    *)
       git checkout go1.11
    ;;
  esac

In the same way that the version of a build dependency can change on different architectures, a component of the project can be built or configured in a different manner. Override-build is another directive that is used to change the building process. The code snippet below is used to build a Linux kernel with a specific configuration file depending on the system architecture.

kernel:
  source: https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.14.67.tar.xz
  source-type: tar
  plugin: kernel
  override-build: |
    case "$(arch)" in
    "x86_64")
    config=x86_64_kata_kvm_4.14.x
    ;;
    "ppc64le")
      config=powerpc_kata_kvm_4.14.x
    ;;

    "aarch64")
      config=arm64_kata_kvm_4.14.x
    ;;
  esac

  cp ${SNAPCRAFT_STAGE}/kernel/configs/${config} .config
  make -s oldconfig EXTRAVERSION=".container" > /dev/null
  make -j $(nproc) EXTRAVERSION=".container

Launchpad branches

Julio then further streamlined the usage by refactoring the snapcraft.yaml and associated tooling so that Kata is now being built in Launchpad and available for all supported architectures.

Indeed, Kata Containers is a multi-architecture project with a growing community that needs open build systems to release new versions of Kata. Launchpad is a open collaboration platform that can be used to build and release software packages for any architecture. Kata Containers project relies on Launchpad to build and release snaps in the Snap Store.

The Kata Containers project supports stable branches. CVE patches are backported into each stable branch, and new releases made. The Kata repository in Launchpad is linked with the upstream repository. That way, the branches are updated automatically, making build and release process of snaps easier and faster.

Kata still uses classic confinement, but Intel’s team is keen to restrict it, and we will explore whether Kata will either require a custom broad access interface or make use of several existing interfaces such as docker and kvm. We also discussed the option to move to core18 for when the project upgrades their qemu stack, which is currently being planned for their next release.

More to come.

Photo by Alci Alliata on Unsplash.