Skip to content
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 riscv64 #42

Closed
liberodark opened this issue Jan 10, 2024 · 6 comments · Fixed by #168
Closed

Add Support for riscv64 #42

liberodark opened this issue Jan 10, 2024 · 6 comments · Fixed by #168
Labels
enhancement New feature or request feature

Comments

@liberodark
Copy link

Hi,

I know it's going to take you a while before you make a release.
But I would like you to consider releasing support for riscv64.
Also I propose to provide riscv64 servers if necessary.

Best Regards

@naphelps naphelps added enhancement New feature or request feature labels Jan 10, 2024
@cipherboy
Copy link
Member

It looks like Go toolchain already supports riscv64; it'd be interesting to see what fails if you attempt a build @liberodark. I don't presently have access to riscv hardware ATM, though could try playing with emulation sometime.

@liberodark
Copy link
Author

liberodark commented Jan 10, 2024

Hi, i can try to build this app.
Also have build other apps in go on riscv64 hardware with success.
PS : My Goal is to open cluster riscv64 server for developpers want to access on riscv64 hardware and that for free.

@liberodark
Copy link
Author

liberodark commented Jan 10, 2024

My build :

apt install -y golang-go rsync gpg git
git clone https://github.com/openbao/openbao
cd openbao
git checkout development
make

With (development) on riscv64 & x86_64 :

==> Building...
# github.com/openbao/openbao/helper/testhelpers/teststorage
helper/testhelpers/teststorage/teststorage.go:264:10: cannot use logicalKv.Factory (value of type func(ctx "context".Context, conf *"github.com/hashicorp/vault/sdk/logical".BackendConfig) ("github.com/hashicorp/vault/sdk/logical".Backend, error)) as "github.com/openbao/openbao/sdk/logical".Factory value in map literal
# github.com/openbao/openbao/helper/builtinplugins
helper/builtinplugins/registry.go:102:26: cannot use credAliCloud.Factory (value of type func(ctx "context".Context, conf *"github.com/hashicorp/vault/sdk/logical".BackendConfig) ("github.com/hashicorp/vault/sdk/logical".Backend, error)) as "github.com/openbao/openbao/sdk/logical".Factory value in struct literal
helper/builtinplugins/registry.go:109:28: cannot use credAzure.Factory (value of type func(ctx "context".Context, c *"github.com/hashicorp/vault/sdk/logical".BackendConfig) ("github.com/hashicorp/vault/sdk/logical".Backend, error)) as "github.com/openbao/openbao/sdk/logical".Factory value in struct literal
helper/builtinplugins/registry.go:110:28: cannot use credCentrify.Factory (value of type func(ctx "context".Context, conf *"github.com/hashicorp/vault/sdk/logical".BackendConfig) ("github.com/hashicorp/vault/sdk/logical".Backend, error)) as "github.com/openbao/openbao/sdk/logical".Factory value in struct literal
helper/builtinplugins/registry.go:112:28: cannot use credCF.Factory (value of type func(ctx "context".Context, conf *"github.com/hashicorp/vault/sdk/logical".BackendConfig) ("github.com/hashicorp/vault/sdk/logical".Backend, error)) as "github.com/openbao/openbao/sdk/logical".Factory value in struct literal
helper/builtinplugins/registry.go:113:28: cannot use credGcp.Factory (value of type func(ctx "context".Context, conf *"github.com/hashicorp/vault/sdk/logical".BackendConfig) ("github.com/hashicorp/vault/sdk/logical".Backend, error)) as "github.com/openbao/openbao/sdk/logical".Factory value in struct literal
helper/builtinplugins/registry.go:115:28: cannot use credJWT.Factory (value of type func(ctx "context".Context, c *"github.com/hashicorp/vault/sdk/logical".BackendConfig) ("github.com/hashicorp/vault/sdk/logical".Backend, error)) as "github.com/openbao/openbao/sdk/logical".Factory value in struct literal
helper/builtinplugins/registry.go:116:28: cannot use credKerb.Factory (value of type func(ctx "context".Context, c *"github.com/hashicorp/vault/sdk/logical".BackendConfig) ("github.com/hashicorp/vault/sdk/logical".Backend, error)) as "github.com/openbao/openbao/sdk/logical".Factory value in struct literal
helper/builtinplugins/registry.go:117:28: cannot use credKube.Factory (value of type func(ctx "context".Context, conf *"github.com/hashicorp/vault/sdk/logical".BackendConfig) ("github.com/hashicorp/vault/sdk/logical".Backend, error)) as "github.com/openbao/openbao/sdk/logical".Factory value in struct literal
helper/builtinplugins/registry.go:119:28: cannot use credOCI.Factory (value of type func(ctx "context".Context, conf *"github.com/hashicorp/vault/sdk/logical".BackendConfig) ("github.com/hashicorp/vault/sdk/logical".Backend, error)) as "github.com/openbao/openbao/sdk/logical".Factory value in struct literal
helper/builtinplugins/registry.go:120:28: cannot use credJWT.Factory (value of type func(ctx "context".Context, c *"github.com/hashicorp/vault/sdk/logical".BackendConfig) ("github.com/hashicorp/vault/sdk/logical".Backend, error)) as "github.com/openbao/openbao/sdk/logical".Factory value in struct literal
helper/builtinplugins/registry.go:120:28: too many errors
make: *** [Makefile:39: dev] Error 1

With (release/1.14.x) Compilation work on riscv64 & x86_64 :

git checkout release/1.14.x
make

Build x86_64 :
Vault v1.14.9 ('8993802145833ab01d49c6070d787a9eccb81546'), built 2023-12-20T17:56:32Z

Build riscv64 :
Vault v1.14.9 ('8993802145833ab01d49c6070d787a9eccb81546'), built 2023-12-20T17:56:32Z

@cipherboy
Copy link
Member

@liberodark This looks good :) I think then, when we get more mature and have CI up and running, we'll want to sync on getting access to these RISC-V build machines and setting up a CI/testing pass on them, but in the mean time, I think we can call this good to start!

cipherboy pushed a commit to cipherboy/openbao that referenced this issue Jan 21, 2024
cipherboy pushed a commit to cipherboy/openbao that referenced this issue Jan 21, 2024
Co-authored-by: hc-github-team-secure-vault-ecosystem <hc-github-team-secure-vault-ecosystem@users.noreply.github.com>
@liberodark
Copy link
Author

Im adding link of website if you want access to RISC-V hardware : https://open-riscv-initiative.com/

cipherboy added a commit to cipherboy/openbao that referenced this issue Mar 3, 2024
This retains the original HashiCorp upstream build & test pipelines,
cleaning them up for OpenBao and removing HashiCorp internal tooling
references that aren't necessary for us.

The CI pipeline currently fails with test errors and commenting will
need to be tested on the main repository with an appropriately scoped
token. However, builds pass and produce usable, unsigned artifacts.

This can form the basis of a proper (signed) release pipeline
eventually, taking actions from the build stage of the tagged
release commit and signing and verifying them.

In order to fix CI, some changes to the Go modules were done, removing
redundant tooling packages and re-adding the kubernetes integration
tests. This also fixes CI to correctly run api & sdk tests, fixing openbao#61
again.

Removed, unnecessary actions:

 - actionlint was used to allow-list actions upstream,
 - add-hashicorp-contributed-label was used to add a label to internal
   PRs for visibility,
 - backport was the tool to automatically backport PRs,
 - milestone-checker was used to ensure PRs had appropriate milestones
   prior to merge,
 - oss was used to classify issues against the specified label category
 - remove-labels was used to clean up issues & PRs
 - security-scan requires internal tooling not made public
 - test-ci-bootstrap & test-ci-cleanup are both part of the complex Enos
   integration tests, which were removed in
   85455fb due to resource
   requirements.

Resolves: openbao#31
Resolves: openbao#42
Resolves: openbao#152
Related: openbao#153

Signed-off-by: Alexander Scheel <alexander.m.scheel@gmail.com>
@cipherboy
Copy link
Member

@liberodark I finally got around to fixing the build pipelines, #168 should add RISC-V support for you :-)

naphelps pushed a commit to cipherboy/openbao that referenced this issue Mar 5, 2024
This retains the original HashiCorp upstream build & test pipelines,
cleaning them up for OpenBao and removing HashiCorp internal tooling
references that aren't necessary for us.

The CI pipeline currently fails with test errors and commenting will
need to be tested on the main repository with an appropriately scoped
token. However, builds pass and produce usable, unsigned artifacts.

This can form the basis of a proper (signed) release pipeline
eventually, taking actions from the build stage of the tagged
release commit and signing and verifying them.

In order to fix CI, some changes to the Go modules were done, removing
redundant tooling packages and re-adding the kubernetes integration
tests. This also fixes CI to correctly run api & sdk tests, fixing openbao#61
again.

Removed, unnecessary actions:

 - actionlint was used to allow-list actions upstream,
 - add-hashicorp-contributed-label was used to add a label to internal
   PRs for visibility,
 - backport was the tool to automatically backport PRs,
 - milestone-checker was used to ensure PRs had appropriate milestones
   prior to merge,
 - oss was used to classify issues against the specified label category
 - remove-labels was used to clean up issues & PRs
 - security-scan requires internal tooling not made public
 - test-ci-bootstrap & test-ci-cleanup are both part of the complex Enos
   integration tests, which were removed in
   85455fb due to resource
   requirements.

Resolves: openbao#31
Resolves: openbao#42
Resolves: openbao#152
Related: openbao#153

Signed-off-by: Alexander Scheel <alexander.m.scheel@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request feature
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants