-
Notifications
You must be signed in to change notification settings - Fork 456
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 RISC-V #346
Conversation
Signed-off-by: Antony Chazapis <[email protected]>
Signed-off-by: Antony Chazapis <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@Anarkis do we have RISC-V machines for building?
There is no need to build natively on RISC-V. The patch sets |
We still have CI test before releasing, so RISC-V is required...
Need to check it. |
@chazapis |
While we have some hardware in our lab, we generally use QEMU for testing on RISC-V. However, I am not sure how this would tie up with running the CI jobs using Drone... On the other hand, since the RISC-V community is still small, I think it would be perfectly acceptable to publish a build marked as experimental/untested. |
@chazapis It sounds good. |
@chazapis I'm fine with the other changes. Could you please update the README.md to include instructions on building the image for the RISC-V platform? I think RISC-V users can build the image by themselves first. WDYT? |
@derekbit, I think it is worth trying to include a RISC-V image in each release. As local-path-provisioner is meant to run in containerized form within Kubernetes, it is not really helpful to tell users to recompile and package up everything themselves. The goal is to run K3s out of the box on RISC-V. In a recent discussion with @brandond in the respective K3s PR, he also mentions that the most important issue for RISC-V support right now is the lack of architecture-compatible container images. So, if there is any way that local-path-provisioner can build and release RISC-V images, I suggest that we pursue that path. If it requires more work, I am eager to help. On the other hand, if you think that this is not possible at this point, I can remove the Drone.io part of this PR and add it in another. |
Let's set the milestone to v0.0.28 |
@chazapis |
I can confirm that v0.0.29 works fine. I just tested it on a RISC-V VM with Ubuntu. The logs: # kubectl logs -n kube-system local-path-provisioner-6b6dfb894d-ldhpv
I0919 10:49:08.242741 1 controller.go:824] "Starting provisioner controller" component="rancher.io/local-path_local-path-provisioner-6b6dfb894d-ldhpv_a9c72231-99ef-458b-be99-4cef9160735b"
I0919 10:49:08.451079 1 controller.go:873] "Started provisioner controller" component="rancher.io/local-path_local-path-provisioner-6b6dfb894d-ldhpv_a9c72231-99ef-458b-be99-4cef9160735b" I see that Alpine containers now support the Thank you! |
Let's close the PR. Thank you. |
Adds the RISC-V architecture to the scripts involved in building and packaging Local Path Provisioner; no code changes.
The resulting container has been tested in QEMU with a RISC-V build of K3s and is working fine.
Notes
riscv64
binary is generated by cross-compilation when$ARCH == riscv64
.ci
script are skipped (options set viaSKIP_TEST
andSKIP_VALIDATE
environment variables).