Hi,
I have a few questions about containerd’s ARM support I wanted to ask before potentially submitting a PR.
-
Is there a reason why in platforms/database.go armhf does not have a variant? I was under the impression that armhf would correspond to a variant of “v7”— if v7 is implied when arch is “arm” and variant is “”, then why is the variant set to “v7” if normalizeArch(“arm”, “v7”) is called?
-
I also noticed on this line when comparing the current platform with the platform the image was intended for, only the OS and Architecture from the image are passed to matcher.Match(). Because the Match() function compares the OS, Architecture, and Variant, the current platform’s variant will always be compared to the image’s variant, which is just an empty string. It seems like the reason only the image’s OS and Architecture are passed into Match is because the oci spec for Image only has OS and Architecture fields, but not a Variant field. Is this intentional to specify Variant in an image index but not a specific image config? This may be a better question to ask in the image-spec repo but it seems like it’s pretty closely tied with this repo.
I was getting an error earlier of
2018/02/15 00:03:55 manifest sha256:7cf526a2f8056e04b50140020ebedaa73539fae967d5f04004fa34c1d4a9a859: not found when unpacking an image because my architecture is armv7 (so Architecture = “arm” and Variant = “v7”) and I was trying to use an image that did not provide an image list, so my Variant of “v7” was being compared to the image’s Variant of “” (because of the image oci spec not having a Variant field). I fixed this for my own purposes by just setting my Variant of “v7” to “” and being extra sure that the image I was pulling was built for armv7, but this is way too hacky and I’m hoping there’s a better way (maybe something that would come out of #2029?)
Hi,
I have a few questions about containerd’s ARM support I wanted to ask before potentially submitting a PR.
Is there a reason why in
platforms/database.goarmhf does not have a variant? I was under the impression that armhf would correspond to a variant of “v7”— if v7 is implied when arch is “arm” and variant is “”, then why is the variant set to “v7” ifnormalizeArch(“arm”, “v7”)is called?I also noticed on this line when comparing the current platform with the platform the image was intended for, only the OS and Architecture from the image are passed to
matcher.Match(). Because theMatch()function compares the OS, Architecture, and Variant, the current platform’s variant will always be compared to the image’s variant, which is just an empty string. It seems like the reason only the image’s OS and Architecture are passed into Match is because the oci spec for Image only has OS and Architecture fields, but not a Variant field. Is this intentional to specify Variant in an image index but not a specific image config? This may be a better question to ask in the image-spec repo but it seems like it’s pretty closely tied with this repo.I was getting an error earlier of
2018/02/15 00:03:55 manifest sha256:7cf526a2f8056e04b50140020ebedaa73539fae967d5f04004fa34c1d4a9a859: not foundwhen unpacking an image because my architecture isarmv7(so Architecture = “arm” and Variant = “v7”) and I was trying to use an image that did not provide an image list, so my Variant of “v7” was being compared to the image’s Variant of “” (because of the image oci spec not having a Variant field). I fixed this for my own purposes by just setting my Variant of “v7” to “” and being extra sure that the image I was pulling was built for armv7, but this is way too hacky and I’m hoping there’s a better way (maybe something that would come out of #2029?)