Skip to main content

Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting us. A member of our team will be in touch shortly. Close

  1. Blog
  2. Article

Igor Ljubuncic
on 3 January 2019


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.

Related posts


Aaron Prisk
3 April 2024

Creating Snaps on Ubuntu Touch

Community Article

This article was written in collaboration with Alfred E. Neumayer of the UBports Project. Tablets, phones and current technology’s capabilities are phenomenal. Who would have thought a thin, light, barely 10 inch device would provide all the power necessary to run Virtual Machines, wherever one desires while powered on battery? That a sma ...


Holly Hall
15 January 2024

Managing software in complex network environments: the Snap Store Proxy

Internet of Things Article

As enterprises grapple with the evolving landscape of security threats, the need to safeguard internal networks from the broader internet is increasingly important. In environments with restricted internet access, it can be difficult to manage software updates in an easy, reliable way. When managing devices in the field, change management ...


Igor Ljubuncic
21 December 2023

We wish you RISC-V holidays!

HPC Article

There are three types of computer users: the end user, the system administrator, and the involuntary system administrator. As it happens, everyone has found themselves in the last group at some point or another; you sit down to perform a task relevant to your needs or duties, but suddenly the machine does not work as ...