-
Notifications
You must be signed in to change notification settings - Fork 245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for arm64, armV7, armV8 #426
Comments
I would be interested in this as well. Can you elaborate on what kind of work is required to make this happen? From the previous PRs, it doesn't seem that a great deal of code is required. |
One is currently being maintained in parity with upstream |
Great! Maybe this can be merged upstream? |
@marquiz We can easily do this with github actions
|
The only question is does |
Yeah, sure. But we use prow for building images |
Any updates on this? |
@marquiz Are there any plans to progress with this issue? |
Hmm, kubernetes test-infra might actually support docker buildx nowadays so we could do this. What needs to be done is
Patches are welcome 😄 |
Best example I could find is https://github.com/kubernetes-sigs/service-catalog/blob/master/Makefile#L343 |
With docker buildx you shouldn't need that. Just something like |
kubernetes/test-infra#22977 enables |
We need to watch the output of
|
https://hub.docker.com/r/raspbernetes/node-feature-discovery - these guys have done multi-arch support several months ago. I don't know how exactly that was done, but this container works without issues. |
I think they use docker buildx: https://github.com/raspbernetes/multi-arch-images |
https://hub.docker.com/r/raspbernetes/node-feature-discovery is not a kubernetes-sigs repo, using prow, I think the main idea is to use prow as our official image builder right? |
If prow isn't sufficient to emulate other arch's and there isn't infra to natively build on other arch's why use it? Is there a requirement? I know of other sigs building multi-arch. Other arch's exist and this helps adoption greatly <3 |
Yes. We use k8s test infra (prow) for CI and we're staying there as that tightly coupled with k8s container image hosting (k8s.gcr.io). Moreover, we want to serve all the container images from a single registry.
I'm a bit lost here 🧐 As I commented earler, afaiu prow nowadays supports multiarch builds via docker buildx. And afaiu, Raspbernetes uses the same build method. We just need a PR in NFD for enabling multiarch builds with docker buildx |
+1 This would be really handy to discover features on Jetson Xaviers |
FWIW, I build (local) multiarch (arm64/amd64) docker images of NFS using this commandline:
Should not be too difficult to patch up the makefile to do this by default. Maybe it needs some var containing the supported platforms, it's a matter of taste. |
@jonkerj running your command returns Done setting up docker in docker.
+ WRAPPED_COMMAND_PID=174
+ wait 174
+ scripts/test-infra/build-image.sh
namespace: node-feature-discovery
image: k8s.gcr.io/nfd/node-feature-discovery:v0.10.0-devel-2-g58e147d
docker buildx build --platform linux/amd64,linux/arm64 --build-arg VERSION=v0.10.0-devel-2-g58e147d \
--target full \
--build-arg HOSTMOUNT_PREFIX=/host- \
--build-arg BASE_IMAGE_FULL=debian:buster-slim \
--build-arg BASE_IMAGE_MINIMAL=gcr.io/distroless/base \
-t k8s.gcr.io/nfd/node-feature-discovery:v0.10.0-devel-2-g58e147d \
\
./
error: multiple platforms feature is currently not supported for docker driver. Please switch to a different driver (eg. "docker buildx create --use")
make: *** [Makefile:70: image] Error 1 |
After splitting out the build by platform, is seems to work ok -> cbd42af |
It could be a feature/limitation of your docker environment or buildx initialization, above invocation works for me (docker 20.10.8 / buildx v0.6.1 / moby/buildkit:buildx-stable-1) |
The Raspbernetes project automatically builds multi-arch images of several projects, including NFD. You could take a look at the workflow file, which essentially wraps |
Is not "my" environment, is kubernetes/test-infra prow environment, the one we use for all NFD CI and image building |
@disconn3ct We're talking here about arm32v7 and arm64v8 right? Those are the terms docker buildx understands. Just to be at the same page. |
@marquiz That was merged over half a year ago, to a release done on March.
Is this ticket still open until all ARM targets supported by dockerx have been added? |
hi guys,
|
Probably because you don't have cross-build tools for c code. Try docker buildx ( |
ok , thanks. |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
/remove-lifecycle stale |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/reopen v0.15.3 does not work on armv7l
|
@Links2004: You can't reopen an issue/PR unless you authored it or you are a collaborator. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@Links2004 would you be willing to work on this? |
sure, can make some free time for this next week. |
/reopen |
@ArangoGutierrez: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
What would you like to be added:
There is no arm support. It would be good to see support this for those architectures.
Why is this needed:
Getting "standard_init_linux.go:219: exec user process caused: exec format error" for pods scheduled on arm nodes.
Usually it's easy to do - just making image multi-architecture =)
The text was updated successfully, but these errors were encountered: