These utilities resulted in the platforms package to have the containerd
API as dependency. As this package is used in many parts of the code, as
well as external consumers, we should try to keep it light on dependencies,
with the potential to make it a standalone module.
These utilities were added in f3b7436b61,
which has not yet been included in a release, so skipping deprecation
and aliases for these.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This cleans up the platforms package from dependencies that are not strictly
needed. This is in preparation of making this package a separate module, which
can be shared by plugins, and containerd versions (as well as external consumers),
- Remove dependency on the errdefs package: most uses of these error
definitions were used internally, and other errors may not be useful
for external consumers as sentinel errors.
- ErrInvalidArgument may be a potential exception, although a look at
current uses of this package shows that there's no special handling of
invalid parameters vs other errors (all would boil down to "the passed
platform is invalid" (either the format, or parsing is not implemented
on a specific platform)
- Remove uses of the convenience "Platform" alias in favor of using the
upstream (from OCI spec). Consumers of this package can still use the
convenience alias, but make sure that function signatures do not imply
that it's a different type (which can cause confusion).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Fill OSVersion field of ocispec.Platform for windows OS in
transfer service plugin init()
- Do not return error from transfer service ReceiveStream if
stream.Recv() returned context.Canceled error
Signed-off-by: Kirtana Ashok <kiashok@microsoft.com>
Helpers to convert from a slice of platforms to our protobuf representation
and vice-versa appear a couple times. It seems sane to just expose this facility
in the platforms pkg.
Signed-off-by: Danny Canter <danny@dcantah.dev>
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>
