rust-vmm/rust-vmm-container

Container with all dependencies required for running rust-vmm crates integration tests.

rust-vmm-container's Issues

Re-add information about commit in docker build

As part of #73 we are removing the information about the commit on which we build the crate. We should find a way to read this from the github workflow and re-add that information to the container for reproducibility purposes.

Add cargo clippy to aarch64 container

Cargo clippy is available for aarch64 starting with the Rust 1.34.0 release.

Fixed rust version in Docker files

We should have a fixed version of rust so we make sure that new builds of the container are reproducible.

We should also use different tags (and not latest).

rustfmt and clippy not available for aarch64 since 1.36.0

aarch64 being a tier-2 Rust architecture, both rustfmt and clippy are not available for the 2 aarch64 toochains (musl and glibc) that we use, since 1.36.0.

Nightly (2019-12-16) has those 2 available for aarch64 though.

We just updated our CI container Dockerfile toolchain to 1.39.0, but since our buildkite default scripts run clippy on aarch64, we can not switch to the newly built container. Potential solutions:

1. Use a fixed nightly toolchain (2019-12-16 for example) for the aarch64 CI container until the next stable release supports clippy for that architecture.
2. Skip clippy check from our default buildkite pipeline

Update cargo-audit

The latest vulnerability advisory format change (rustsec/advisory-db#414) requires cargo-audit >= v0.12.0. The container currently runs v0.11.2.

install rust nightly

This is needed so we can run cargo fmt on examples as well.

To be able to run it, there will be some other changes needed.

Dockerfiles for x86 and aarch64 are very similar

Can we have a "basic" Docker file (I think that might be a layer) that Dockerfile.x86_64 and Dockerfile.aarch64 can inherit from so we don't have so many duplicated commands in both files? Then depending on the architecture we can have other specific commands on top of the common layer.

Fix docker.sh script - deprecated dockerhub API

We were relying on the dockerhub v1 API to fetch the latest published tag. This was deprecated in the meantime, and we need to update the script to use v2.

Here are some details about the update: https://www.docker.com/blog/docker-hub-v1-api-deprecation/

Add tools to run bindgen

The containers used for builds currently don't have necessary tools to compile bindgen stuff, which compiles few C files and create rust bindings.

The tools required are:

• libclang-dev
• clang
• musl-tools

We also need to configure the container to pass the include path, to the Linux libraries, for the musl build, else we get more errors like "const.h" not found.

This pull request should build from the container if this works fine:

rust-vmm/vhost-device#68

Upgrade Rust toolchain

The container currently runs with Rust 1.39.0, which is a bit outdated. The latest is 1.44.0.

Support SSH Git URLs for authenticated connections to private repositories

Cargo supports ssh git URLs, but the libgit2 library depends on ssh-agent to handle ssh authentication.
Could we add openssh-server to support ssh git URLs?

Use version tags instead of latest

Right now the container has an x86_64 and a aarch64 tags. When you're pulling the latest version it will download one of the builds based on the platform you're running on.

Instead of using latest we should use version tags so that updates to container are not immediately visible to the consumers. Otherwise we might end up in situations in which the build for rust-vmm crates is broken due to updates to the Rust versions. Such updates should be controlled and explicit.

Processes in container run as root

Running as root is unfortunately this is the default configuration when running a container. The simplest way to make the processes to run as something else is to provide a UID when running the container:
docker run --user 100

The problem is that the Rust toolchain is installed per user and as of now there is no official way of installing it system-wide (at least I didn't find one). Some more details in this issue: rust-lang/rustup#313

We need to find a way around this that is not adding complexity to running the container (like creating a user only for running the container) because this container is used by both automated systems (like Buildkite), but also by developers who want to test their code on their local machines.

Support performance tests

Enhance the Docker image with the necessary tools to run performance tests.

Add script for building the Windows container

Right now the container is only built on Linux using the docker.sh script.
We also need a script that does the same for Windows.

Once this is done, we can update the manifest command of docker.sh such that we create a manifest including the windows image.

Install boto3

This is needed for downloading test resources from S3.

Create script for publishing new container versions

We now have manual steps that we need to do for publishing a new container versions. These are only available for the Linux container. We should create a script that does:

• docker build
• docker tag (to find the version can we somehow read the latest available version from docker, and just incremented by one?)
• docker publish

We should make sure that the windows & linux containers have the same versions.

Once these scripts are available, we can setup a CI such that the builds happen on every commit that changes the docker files.

Create a script for managing Dockerfiles

We currently have two docker files: one for Windows and one for Linux. It is easy for them to get out of sync. We should have a way for updating the Rust version uniformly for both OSs.

Downgrade rust version to one where the aarch64 musl target works

The latest version of the rust-vmm container breaks the aarch64-musl builds. We need to downgrade the Rust version to the last known one that works.

Tracking Rust issue: rust-lang/rust#79791

[Docker Registry] Move container from fandree to rust-vmm

Currently the container is hosted on Docker Hub in my personal profile. We now have a rust-vmm profile on Docker Hub and the container should be moved there.

In doing so we will also need to:

• modify all existing Buildkite pipelines that are pulling the container
• modify the readme of this repository
• modify the readme of all repositories that are mentioning it (kvm-ioctls, vm-virtio, others?)

Create a buildkite pipeline that builds the container on each PR

This way we ensure that we don't introduce bugs as we add tools to the container.

This pipeline should call docker.sh on both x86_64 and on aarch64. Once we have a Windows script available (#49), that script should also be called.

Upgrade to newer ubuntu for the base image

The version of ubuntu that we are using is pretty old, and it also comes with an old glibc version. This is causing problems when building newer busybox versions (which we are need for testing vmm-reference).

Upgrade to Rust 1.51.1

There are some goodies in this version.

Notably, as @lauralt discovered, if you use as dev-dependency features of a normal leak into the release builds.
What does this mean?

If you have a dependency as follows:

[dependencies]
vm-memory = ">=0.4.0"

[dev-dependencies]
vm-memory = { version = ">=0.4.0", features = ["backend-mmap", "backend-atomic" ] }

then the vm-memory features ("backend-mmap" and "backend-atomic") leak into non-dev builds, and thus can be used in non test scenarios.

This can generate all sorts of programming errors. If we take the example of vm-memory, we do not have the mmap feature exported by default on purpose such that other library crates only depend on the interface, and not on the mmap implementation. With this leak, crates might use GuestMemoryMmap by mistake instead of the GuestMemory trait, and introduce an unwanted dependency on the implementation details. It is common that consumers of vm-memory use as a dev-dependency the backend-mmap feature because it makes it easier to write unit tests.

By upgrading to 1.51.1, we can make this problem go away by specifying the resolver version to be 2.

The newer Rust version was also requested by @keiichiw here and would provide some simplifications to the vhost crate.

Install pexect

Add pexpect to the container. This can be used for sending commands to the VM (in vmm-reference) and get the output from them nicely.

Docker build workflow cannot be set as required

The build does not show up when searched for in the branch protection settings.

Add shell script linter to container image

Good candidate: https://github.com/koalaman/shellcheck

Add workflow for publishing containers versions

There are some existing github workflows that allow publishing a new version on push to main. This might be a bit too much, because we might want to capture more PRs in a single release. It would be nice instead to be able to publish a new container when we push a version tag to signal that we want a release.

Add pytest-timeout to container image

There are several layers of timeouts in tests to protect the CI from never ending tests:

• in-test timeouts - up to the test author to add these
• pytest timeouts - require the pytest-timeout plugin to be installed (hence this issue) - if the above is missing, these will terminate a pytest run
• buildkite pipeline timeouts - configured per pipeline

[Docker Registry] Move container from lpetrut/rust_win_buildtools to rust-vmm

Currently the container is hosted on Docker Hub in Lucien's profile. We now have a rust-vmm profile on Docker Hub and the container should be moved there.

In doing so we will also need to:

• modify all existing Buildkite pipelines that are pulling the container
• modify the readme of this repository
• modify the readme of all repositories that are mentioning it (kvm-ioctls, vm-virtio, others?)

Cargo audit does not seem to be installed on arm anymore

This makes the cargo audit test fail when running on an arm platform.
Failure example: https://buildkite.com/rust-vmm/kvm-bindings-ci/builds/139#01874646-cd0e-4772-b671-a7644ccc2522

Possible need of a Docker Hub repository to store container image for RISC-V CI

Hi, here is a problem I'm facing while enabling rust-vmm CI for RISC-V.
Feel free to leave your suggestions. Thanks in advance.

Background:
Buildkite doesn't support RISC-V agents platform.
Therefore, I've proposed doing RISC-V CI inside QEMU running on x86_64.metal Buildkite platform (see #91).
In other words, Docker image for RISC-V CI will be very different from the existing images for x86/ARM CI.

Problem:
To accommodate such a different Docker image for RISC-V CI,
the existing Docker Hub repository rustvmm/dev cannot be reused to store the image.

Possible solutions:

1. Create a new Docker Hub repository, e.g. rustvmm/dev_riscv64 to store the image.
2. Wait until Buildkite supports RISC-V agents platform. Meanwhile, maybe RISC-V community can maintain separate GitHub fork of kvm-ioctls with RISC-V support (just like having patches accepted into RISC-V Linux kernel tree first, before merging into mainline Linux kernel).
3. Or meanwhile, manually review and accept riscv-related pull requests to rust-vmm.