The background for this change:
1. Windows host-process containers do not have an OS version set
2. Buildx v0.10 started pushing manifest lists by default, but it never
has the OSVersion in the platform data (not that there is any way to
specify what particular OS version you want). The change means that
containerd cannot run images created with the new buildx on Windows
because there is no matching OSVersion in the list of manifests.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Add unit test to function GetCPUVariantFromArch
Fix import issue on non-linux platforms
Fix some style issue
Signed-off-by: Tony Fang <nenghui.fang@gmail.com>
When images/containers in ARM arch were built/executed on x86 host,
getCPUVariant will fail as it tries to look for /proc/cpuinfo, whose
content is from the host. Adding a new method as fallback to check uname
machine when it happens.
Signed-off-by: Tony Fang <nenghui.fang@gmail.com>
This allows running Linux containers on FreeBSD and modifies the
mounts so that they represent the linux emulated filesystems, as per:
https://wiki.freebsd.org/LinuxJails
Co-authored-by: Gijs Peskens <gijs@peskens.net>, Samuel Karp <samuelkarp@users.noreply.github.com>
Signed-off-by: Artem Khramov <akhramov@pm.me>
The output of platforms.DefaultSpec() and the normalized version of the
default platform on 32- and 64-bit ARM are not comparable. This test
was added to validate not losing Windows-specific information during
normalize of the platform object, so for now we are moving this to be a
Windows-only test until we resolve the right behavior on ARM.
Signed-off-by: Phil Estes <estesp@amazon.com>
Commit fb0688362c implemented the Normalize()
function, but marked these fields as deprecated.
It's unclear what the motivation was for this, as the fields are part of the OCI
Image spec. On Windows, the OSVersion field specifically is important when matching
images (as kernel versions may not be compatible).
This patch updates platforms.Normalize() to preserve the OSVersion and OSFeatures
fields.
As a follow-up, we should look at defining an appropriate string-representation
for these fields (possibly as part of the OCI Spec), and update platforms.Parse()
accordingly.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Correctly matches optional variants for amd64
arch. These should be used for standardized values
v1-v4 from https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels.
V1 remains the default and is cleared by default.
Pulling a higher variant will match the highest
available platform lower or equal to the provided one
when platformVector is used.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
GA for ws2022 github actions VMs launched a couple weeks ago so seems like
it's time to try out the CI on this new SKU.
This involved adding new ws2022 runs for the OS matrices in the CI, fixing up
a test in the platforms package and adding a mapping for the ws2022 container image in
integration/client.
Signed-off-by: Daniel Canter <dcanter@microsoft.com>
This commit attemts to support containerd on darwin platform. With an
external runtime shim, ctr run should work with, for instance,
--runtime=io.containerd.runu.v1. An example of runtime and shim is
managed under different repository (github.com/ukontainer/runu/).
Signed-off-by: Hajime Tazaki <thehajime@gmail.com>
The Windows Default matcher also checks the the OS Version prefix,
however, the platforms.DefaultSpec does not include it, which means
that it won't match the matcher.
This solves the issue by adding the OS Version to the DefaultSpec.
Signed-off-by: Claudiu Belu <cbelu@cloudbasesolutions.com>
Remove build tags which are already implied by the name of the file.
Ensures build tags are used consistently
Signed-off-by: Derek McGowan <derek@mcg.dev>
This changes platforms.Parse to hit /proc to look up CPU info only when
it's needed, instead of in init(). This makes the package a bit easier
for other packages to consume, especially clients that don't call
platforms.Parse or need to lookup CPU info.
Signed-off-by: Jason Hall <jasonhall@redhat.com>
`OnlyStrict()` returns a match comparer for a single platform.
Unlike `Only()`, `OnlyStrict()` does not match sub platforms.
So, "arm/vN" will not match "arm/vM" where M < N, and "amd64" will not also match "386".
`OnlyStrict()` matches non-canonical forms. So, "arm64" matches "arm/64/v8".
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
This isn't supported by *all* arm64 chips, but it is common enough that I think it's worth an explicit fallback. I think it will be more common for images to have arm64 support without arm support, but even if a user has an arm64 chip that does not support arm32, having it fail to run the arm32 image is an acceptable compromise (because it's non-trivial to detect arm32 support without running a binary, AFAIK).
Also, before this change the failure would've simply been "no such image" instead of "failed to run" so I think it's pretty reasonable to allow it to try the additional 32bit set of images just in case one of them actually does work (like it will on many popular chips like 64bit Raspberry Pis and AWS Graviton).
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
This improves the hard-coded list of ARM fallbacks in the `platform.Only` implementation (by doing a descending loop over variant numbers instead, which is all the hard-coded list was doing).
Making this a separate function can then more easily be recursive later for handling an `arm64`->`arm` fallback (or similar), but I think it makes the code a lot more clear too (so we're calculating a vector of platforms separately from building a matcher object).
This also makes a minor adjustment in `TestImagePullWithDistSourceLabel` which had an implicit assumption that `platforms.Only` would only ever result in a single suitable manifest, which isn't strictly true (and is likely failing as-is when run on any 32bit `arm` system that's `v6` or higher, which this fixes 😅).
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
On the very popular Raspberry Pi 1 and Zero devices, the CPU is actually ARMv6, but the chip happens to support the feature bit the kernel uses to differentiate v6/v7, so it gets reported as "CPU architecture: 7" and thus fails to run many of the images that get pulled.
To account for this very popular edge case, this also checks "model name" which on these chips will begin with "ARMv6-compatible" -- we could also check uname, but getCPUInfo is already handy, low overhead, and mirrors the code before this.
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
Don't rely on /proc/cpuinfo denoting a 64-bit ARMv8 processor if the
runtime detected GOARCH == arm. This allows aarch64 32-bit userspace
distros to run containers properly via a 32-bit runtime.
Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com>
arm has been supported, but something is missing, causes test failure
--- FAIL: TestParseSelector/linux (0.00s)
platforms_test.go:292: arm support not fully implemented: not implemented
--- FAIL: TestParseSelector/macOS (0.00s)
platforms_test.go:292: arm support not fully implemented: not implemented
Signed-off-by: Shengjing Zhu <zhsj@debian.org>
This commit improves ARM platform matching in two instances:
* Some old kernels reported the CPU architecture of arm64 cpus as
Aarch64 [1].
* In cases where the user is running with armv8 cpu and kernel but amrhf
user land (so armhf containerd), a possibility given the compatibility
of armv8 with armv7.
[1] https://elixir.bootlin.com/linux/v3.14.29/source/arch/arm64/kernel/setup.c#L420
Signed-off-by: Jaime Caamaño Ruiz <jcaamano@suse.com>
ARM variant detection logic was authored originally with
POSIX OS in mind. This change leaves POSIX code path unaltered
and adds support to detect ARM variant on Windows by leveraging
runtime.goarch.
Signed-off-by: Jiri Appl <jiria@microsoft.com>
Implements the Windows lcow differ/snapshotter responsible for managing
the creation and lifetime of lcow containers on Windows.
Signed-off-by: Justin Terry (VM) <juterry@microsoft.com>
Adds a new platform interface for matching and comparing platforms.
This new interface allows both filtering and ordering of platforms
to support running multiple platform and choosing the best platform.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
This function is analogous to `regexp.MustCompile` and can simplify production
of a `Platform` from a hard-coded strings, e.g. for global variable
initialisation.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
The normalization was being inconsistently applied causing a
failure to match some platforms in manifest lists.
Fix the matcher and normalization to be more consistent and
add changes to parser to prevent the defaulted variants from being
set in the platform structure.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
