rust-vmm / rust-vmm-container Goto Github PK
View Code? Open in Web Editor NEWContainer with all dependencies required for running rust-vmm crates integration tests.
License: Apache License 2.0
Container with all dependencies required for running rust-vmm crates integration tests.
License: Apache License 2.0
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.
Cargo clippy is available for aarch64 starting with the Rust 1.34.0 release.
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).
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:
clippy
for that architecture.clippy
check from our default buildkite pipelineThe latest vulnerability advisory format change (rustsec/advisory-db#414) requires cargo-audit
>= v0.12.0. The container currently runs v0.11.2.
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.
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.
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/
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:
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:
The container currently runs with Rust 1.39.0, which is a bit outdated. The latest is 1.44.0.
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?
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.
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.
Enhance the Docker image with the necessary tools to run performance tests.
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.
This is needed for downloading test resources from S3.
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:
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.
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.
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
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:
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.
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).
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.
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.
The build does not show up when searched for in the branch protection settings.
Good candidate: https://github.com/koalaman/shellcheck
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.
There are several layers of timeouts in tests to protect the CI from never ending tests:
pytest
timeouts - require the pytest-timeout
plugin to be installed (hence this issue) - if the above is missing, these will terminate a pytest
runbuildkite
pipeline timeouts - configured per pipelineCurrently 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:
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
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:
rustvmm/dev_riscv64
to store the image.kvm-ioctls
with RISC-V support (just like having patches accepted into RISC-V Linux kernel tree first, before merging into mainline Linux kernel).A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.