build: Add support for RISC-V #12067
Conversation
|
I don't know much about RISC-V so I'll defer the review to others who are more experienced |
Signed-off-by: Antony Chazapis <[email protected]>
There was a problem hiding this comment.
IMO, I don't think we should add support for new architectures that do not have significant user requests. In this case, this seems pre-emptive to user requests (correct me if I'm wrong).
Argo CD supports a few different archs, but that doesn't currently include RISC-V. Those different archs do also slow down the build considerably for some rare use-cases.
Adding support for a new arch means a new maintenance burden for that arch. If there are no user requests for that, that maintenance burden seems not worthwhile. Given the unstable status of several upstream projects as you mentioned, that sounds even more maintenance heavy as a result
|
|
||
| RUN apk update && apk add --no-cache \ | ||
| RUN apk update && \ | ||
| (command -v go >/dev/null 2>&1 || apk add --no-cache go) && \ |
There was a problem hiding this comment.
we should add versions if we want this to match the regular alpine images.
this also feels very hacky to have different base images, but it sounds like there's no pre-built Alpine image with Go and Node for RISC-V?
| (command -v node >/dev/null 2>&1 || apk add --no-cache nodejs-current) && \ | ||
| (command -v yarn >/dev/null 2>&1 || apk add --no-cache yarn) && \ |
There was a problem hiding this comment.
same as above re: versioning
@agilgur5, I agree. However, I want to stress out that even though the RISC-V community is still small, it is constantly growing. You may not have user requests now, but RISC-V users currently just run what is available (or recompile). If Argo (and Kubernetes/K3s) were already available, I am sure people would find good use for them. A whole range of RISC-V hardware has been announced. We envision these devices to join a Kubernetes control plane and run partial workflows via Argo. Also, at this point, I think it would be perfectly acceptable to publish a build marked as experimental/untested. In any case, let me know if there is any way I can help. |
|
As an example of previous work in the industry, https://github.com/nodejs/unofficial-builds/ creates experimental builds for less common architectures like RISC-V. We could potentially have something similar in |
|
Closing stale PRs |
agilgur5
added
solution/workaround
agilgur5
added
the
problem/more information needed
|
Hello, as I am using a Kubernetes cluster on RISCV hardware I am now looking for a workflow tool. I would like to use Argo Workflows on RISCV as soon as it is available. |
|
Reflecting on the "no user request" part: Risc V currently has the attention of a nice amount of highly motivated and skilled developers. Supporting the architecture - or at least a sign of strong intent - can make some of them interested in Argo as well. |
The equivalent was said above, but "build and maintain it pre-emptive to an actual need" is not a sustainable maintenance strategy -- following that could make infinite permutations of features -- and Argo already has sustainability issues.
Also neither high skill nor high motivation is needed to create an |
|
I understand your point, and thanks for the clarification. As currently procurable RiscV boards just getting over the RPi3 performance level, things might change in the future as drivers and Kubernetes ecosystem support matures. |
|
Yea I'd personally love to see an open source ISA like RISC-V gain more traction and adoption. Just wouldn't make sense for some projects like Argo to support it as part of core yet as the maintenance would not be worthwhile / sustainable. Community builds make more sense at the current juncture and limited amount of hardware |
This PR adds RISC-V support, by generating a CLI binary for RISC-V and container images.
Motivation
The work is part of an ongoing effort to run K3s on RISC-V. The main functionality is there, so we are now moving to higher-level services and Argo Workflows is first on the list. We expect Argo Workflows to enable us to seamlessly run workflows in a hybrid hardware environment with amd64, arm64, and riscv64 hosts.
Modifications
There are no code changes in this PR, just small additions and modifications in the
Makefileand release scripts.A binary for
riscv64is created by adding the architecture to theMakefile.The container image generation is a bit trickier, as the base images used do not currently support RISC-V. Alpine supports RISC-V in the "edge" branch and distroless has deferred releasing RISC-V images until the Debian unstable branch is moved into stable (estimated in 2025). For this reason, I turned the base image names into arguments in the
Dockerfileand use different ones for RISC-V inrelease.yaml.Verification
I built container images by running the script in
release.yamlby hand. They can be found at my organization's Docker Hub account. I then modifiedinstall.yamlto use these container images and tested Argo Workflows in a QEMU setup with a RISC-V build of K3s. The installation manifest, as well as test workflow can be found here.