| Age | Commit message (Collapse) | Author |
|---|
|
Currently, if containerd is installed locally via tools/installers/containerd,
then it will not necessarily be used if containerd is installed in the system
path. This means that the existing containerd tests are all likely broken.
Also, use libbtrfs-dev instead of btrfs-tools, which is not actually required.
PiperOrigin-RevId: 344879109
|
|
PiperOrigin-RevId: 321053634
|
|
The go.mod dependency tree for the shim was somehow contradictory. After
resolving these issues (e.g. explicitly imported k8s 1.14, pulling a
specific dbus version), and adding all dependencies, the shim can now be
build as part of the regular bazel tree.
As part of this process, minor cleanup was done in all the source files:
headers were standardized (and include "The gVisor Authors" in addition
to the "The containerd Authors" if originally derived from containerd
sources), and comments were cleaned up to meet coding standards.
This change makes the containerd installation dynamic, so that multiple
versions can be tested, and drops the static installer for the VM image
itself.
This change also updates test/root/crictl_test.go and related utilities,
so that the containerd tests can be run on any version (and in cases
where it applies, they can be run on both v1 and v2 as parameterized
tests).
|
|
This change moves all Docker images to a standard location, and abstracts the
build process so that they can be maintained in an automated fashion. This also
allows the images to be architecture-independent.
All images will now be referred to by the test framework via the canonical
`gvisor.dev/images/<name>`, where `<name>` is a function of the path within the
source tree.
In a subsequent change, continuous integration will be added so that the images
will always be correct and available locally.
In the end, using `bazel` for Docker containers is simply not possible. Given
that we already have the need to use `make` with the base container (for
Docker), we extend this approach to get more flexibility.
This change also adds a self-documenting and powerful Makefile that is intended
to replace the collection of scripts in scripts. Canonical (self-documenting)
targets can be added here for targets that understand which images need to be
loaded and/or built.
PiperOrigin-RevId: 308322438
|
|
This change renames the tools/images directory to tools/vm for clarity, and
adds a functional vm_test. Sharding is also added to the same test, and some
documentation added around key flags & variables to describe how they work.
Subsequent changes will add vm_tests for other cases, such as the runtime tests.
PiperOrigin-RevId: 307492245
|
|
This is frequently causing the core build scripts to fail. The core ubuntu
distribution will perform an auto-update at first start, which may cause the
lock file to be held. All apt-get commands may be done in a loop in order to
retry to avoid this issue. We may want to consider retrying other pieces, but
for now this should avoid the most frequent cause of build flakes.
PiperOrigin-RevId: 297704789
|
|
Sometimes, when we start a new instance, the file
lock on "apt" is locked. Add a loop to the master
installer.
In addition, the "apt-get install" fails to register
runsc in docker, so run the appropriate scripts to
get that to happen.
Also, add some helpful log messages.
PiperOrigin-RevId: 296497357
|
|
Change adds the following:
- logic to run from "baked images". See [GVISOR_DIR]/tools/images
- installers which install modified files from a workspace. This
allows users to run benchmarks while modifying runsc.
- removes the --preemptible tag from built GCE instances. Preemptible
instances are much more likely to be preempted on startup, which
manifests for the user as a failed benchmark. I don't currently have
a way to detect if a VM has been preempted that will work for this
change.
https://cloud.google.com/compute/docs/instances/preemptible#preemption_process
https://cloud.google.com/compute/docs/instances/preemptible#preemption_selection
PiperOrigin-RevId: 293697949
|
|
This formalizes the adhoc scripts previously in kokoro. The image targets can
be used by e.g. benchmarks in order to automated image prepation.
PiperOrigin-RevId: 290982744
|
