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

Build arm64 binaries to run on Raspbian OS #1295

Closed
muratkars opened this issue Feb 28, 2018 · 55 comments
Closed

Build arm64 binaries to run on Raspbian OS #1295

muratkars opened this issue Feb 28, 2018 · 55 comments

Comments

@muratkars
Copy link
Member

@muratkars muratkars commented Feb 28, 2018

Usecase: Highly available ownCloud running on Kubernetes cluster

Raspberry Pi 3 model b is cost & power efficient to run ownCloud, but the issue is neither storage nor the nodes can be configured as HA.
I'm running ownCloud on 6 nodes Kubernetes cluster on Raspbian Lite, application availability is achieved, but i can't protect my storage since there is only single SSD attached to each node.
I want to try OpenEBS to see if I can achieve storage availability by replicating with OpenEBS.
Use case is niche and unproven since the resources on Raspberry Pi 3 is limited. OpenFaaS is another common usecase popular on Raspberry.

My cluster specs:
6 nodes K8s cluster running on Raspbian Lite
Each node:
Quad Core 1.2GHz Broadcom BCM2837 64bit CPU
1GB RAM
32 GB SD for OS
512 GB SSD for data

@muratkars
Copy link
Member Author

@muratkars muratkars commented Mar 29, 2018

Quick update for arm64 enthusiasts:
Made some progress here fixing dependencies and building deps for arm64 architecture. Instead of RPi 3 I've used a little bit more powerful SoC called Le Potato from Libre Computer.
Need more testing, and integration with OpenEBS CI/CD before I can send a PR, but in the meantime, if you want to play with it, my images are here

Here some instructions to get started http://containerized.me/arming-kubernetes-with-openebs-1

@muratkars
Copy link
Member Author

@muratkars muratkars commented Apr 6, 2018

My request to get a CI setup hw from WorksOnArm Project is approved.
WorksOnArm/equinix-metal-arm64-cluster#54

Next week I am hoping to spend some time with OpenEBS build team to unify amd64 and arm64 builds and get official builds started.

@jmreicha
Copy link

@jmreicha jmreicha commented Jun 7, 2018

Any update on this? I'm working on an ARM cluster for my home lab and would love to get a storage solution like OpenEBS working.

@vielmetti
Copy link

@vielmetti vielmetti commented Jun 20, 2018

Hi @muratkars @jmreicha I'm hopeful that there's an update here - let me know if there's anything I can do to help from the arm64 cluster side at Packet.

@muratkars
Copy link
Member Author

@muratkars muratkars commented Jun 20, 2018

Hi @vielmetti @jmreicha - Team is working on this. Currently, build and instructions provided here seems to be functional.
Once the 0.6 release is out, a new arm64 build will be released and we will focus back on getting it into CI run on packet and adding few more validation steps for arm64.

@vielmetti
Copy link

@vielmetti vielmetti commented Jun 20, 2018

Thanks @muratkars ! Remind me what your CI infrastructure looks like? I want to make sure we have the right sort of resources ready.

@jmreicha
Copy link

@jmreicha jmreicha commented Oct 1, 2018

@muratkars Can you point me in the right direction for how/where builds happen? I'd like to take see if I can take a stab at this as part of Octoberfest.

@andrei-dascalu
Copy link

@andrei-dascalu andrei-dascalu commented Mar 2, 2019

@muratkars Hello!

I see this is still open and the issue also interests me a lot as I'm working on a k8s cluster on Rock64 boards.
I've tried the instructions at https://blog.openebs.io/arming-kubernetes-with-openebs-1-b450f41e0c1f but it looks like the yml provided aren't available anymore.
Is there something I can do to help with this?

Cheers!

@muratkars
Copy link
Member Author

@muratkars muratkars commented Mar 2, 2019

Thanks @andrei-dascalu . Team is working to get automation of multi-architecture images up soon. In the meantime, I'll try to get the v0.8.1 arm64 built this week and update the issue here. cc @harshvkarn

@bwolf
Copy link

@bwolf bwolf commented Mar 8, 2019

@muratkars Anything new for us waiting for arm64? I'm curious to give OpenEBS a try on my cluster!

@kmova kmova added this to the 0.9 milestone Mar 13, 2019
@kmova
Copy link
Member

@kmova kmova commented Mar 13, 2019

Thanks @bwolf for checking back on this. Added this for 0.9.

@kmova kmova removed this from the 0.9 milestone May 14, 2019
@kmova kmova added this to the 0.9.1 milestone May 14, 2019
@kmova kmova removed this from the 1.0 milestone Jun 11, 2019
@kmova kmova added this to the 1.x Backlog milestone Jun 11, 2019
@dewet22
Copy link

@dewet22 dewet22 commented Jul 14, 2019

@muratkars worth asking about another update? This seems to be slipping without any resolution in sight. With the new RPi4 and other more powerful SBCs using arm64 being available now, this is quite a limitation to wider adoption.

@ibreakthecloud
Copy link
Member

@ibreakthecloud ibreakthecloud commented Jul 15, 2019

@dewet22 This wasn't on the highly active issue until now :) Builds will be coming soon. I'll keep this issue posted. Thanks.

@vielmetti
Copy link

@vielmetti vielmetti commented Aug 26, 2019

@harshvkarn is there an update on this? Thanks!

@ibreakthecloud
Copy link
Member

@ibreakthecloud ibreakthecloud commented Aug 26, 2019

@vielmetti
We were able to build the bare minimum OpenEBS w/ Jiva. I will commit for the official build process very soon.
These are the images for now if you want to test it.

harshvkarn/jiva:arm
harshvkarn/provisioner-localpv:alpine-arm64
harshvkarn/admission-server:arm
harshvkarn/m-apiserver:arm
harshvkarn/node-disk-manager:arm
harshvkarn/node-disk-operator:arm
harshvkarn/openebs-k8s-provisioner:arm

@Cerebus
Copy link

@Cerebus Cerebus commented Sep 11, 2019

@harshvkarn Attempting a deploy in k3s on RPI3B running Ubuntu 18.04.3/aarch64, maya-apiserver dumps out in preflight:

$ kubectl logs maya-apiserver-5d9b995c9-r6nvz
+ MAYA_API_SERVER_NETWORK=eth0
+ grep inet
+ awk {print $2}
+ ip -4 addr show scope global dev eth0
+ cut -d / -f 1
+ CONTAINER_IP_ADDR=10.42.1.5
+ exec /usr/local/bin/maya-apiserver start --bind=10.42.1.5
I0911 01:22:01.742542       6 start.go:153] Initializing maya-apiserver...
preflight checks failed:   --  precheck for bdc failed: the server could not find the requested resource (get blockdeviceclaims.openebs.io)

I could be missing something obvious, so feel free to point out what I could be doing wrong. :)

-- T

@Cerebus
Copy link

@Cerebus Cerebus commented Sep 14, 2019

@harshvkarn Redeployed k8s 1.15.3 w/ kubeadm on ubuntu 18.04/aarch64, . maya-apiserver errors our the same as k3s above (same platform).
ndm-operator errors out:

{"level":"info","ts":1568435605.2400267,"logger":"ndm-operator","msg":"Go Version: go1.12.5"}
{"level":"info","ts":1568435605.240167,"logger":"ndm-operator","msg":"Go OS/Arch: linux/arm64"}
{"level":"info","ts":1568435605.2402081,"logger":"ndm-operator","msg":"operator-sdk Version: v0.5.0"}
{"level":"info","ts":1568435605.2474062,"logger":"leader","msg":"Trying to become the leader."}
{"level":"info","ts":1568435605.8234258,"logger":"leader","msg":"Found existing lock with my name. I was likely restarted."}
{"level":"info","ts":1568435605.8236134,"logger":"leader","msg":"Continuing as the leader."}
{"level":"info","ts":1568435606.252126,"logger":"ndm-operator","msg":"Registering Components"}
{"level":"info","ts":1568435606.2535322,"logger":"kubebuilder.controller","msg":"Starting EventSource","controller":"blockdevice-controller","source":"kind source: /, Kind="}
{"level":"error","ts":1568435606.2538614,"logger":"kubebuilder.source","msg":"if kind is a CRD, it should be installed before calling Start","kind":"BlockDevice.openebs.io","error":"no matches for kind \"BlockDevice\" in version \"openebs.io/v1alpha1\"","stacktrace":"github.com/openebs/node-disk-manager/vendor/github.com/go-logr/zapr.(*zapLogger).Error\n\t/root/go/src/github.com/openebs/node-disk-manager/vendor/github.com/go-logr/zapr/zapr.go:128\ngithub.com/openebs/node-disk-manager/vendor/sigs.k8s.io/controller-runtime/pkg/source.(*Kind).Start\n\t/root/go/src/github.com/openebs/node-disk-manager/vendor/sigs.k8s.io/controller-runtime/pkg/source/source.go:89\ngithub.com/openebs/node-disk-manager/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Watch\n\t/root/go/src/github.com/openebs/node-disk-manager/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:122\ngithub.com/openebs/node-disk-manager/pkg/controller/blockdevice.add\n\t/root/go/src/github.com/openebs/node-disk-manager/pkg/controller/blockdevice/blockdevice_controller.go:53\ngithub.com/openebs/node-disk-manager/pkg/controller/blockdevice.Add\n\t/root/go/src/github.com/openebs/node-disk-manager/pkg/controller/blockdevice/blockdevice_controller.go:36\ngithub.com/openebs/node-disk-manager/pkg/controller.AddToManager\n\t/root/go/src/github.com/openebs/node-disk-manager/pkg/controller/controller.go:13\nmain.main\n\t/root/go/src/github.com/openebs/node-disk-manager/cmd/manager/main.go:88\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:200"}
{"level":"error","ts":1568435606.2542424,"logger":"ndm-operator","msg":"","error":"no matches for kind \"BlockDevice\" in version \"openebs.io/v1alpha1\"","stacktrace":"github.com/openebs/node-disk-manager/vendor/github.com/go-logr/zapr.(*zapLogger).Error\n\t/root/go/src/github.com/openebs/node-disk-manager/vendor/github.com/go-logr/zapr/zapr.go:128\nmain.main\n\t/root/go/src/github.com/openebs/node-disk-manager/cmd/manager/main.go:89\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:200"}

FWIW, ndm-operator gives the same error on k3s, so damnfino what the problem is. Any help?

-- T

@shubham14bajpai shubham14bajpai added this to Pre-commits and Designs - Due: May 31 2020 in 1.11 Release Tracker - Due June 15th. May 21, 2020
@armandleopold
Copy link

@armandleopold armandleopold commented May 26, 2020

Hello, when taking The updated YAML is here: https://openebs.github.io/charts/openebs-operator-arm-dev.yaml, on Raspberry Pi 4 k3s Cluster in aarch64 OS architecture, i am getting all good from the openebs, except for the maya-apiserver

pi@pi1:~ $ kubectl get all -A
NAMESPACE     NAME                                               READY   STATUS             RESTARTS   AGE
openebs       pod/openebs-snapshot-operator-546b77dc67-g54t7     2/2     Running            1          14m
openebs       pod/openebs-ndm-kckk4                              1/1     Running            0          14m
kube-system   pod/coredns-8655855d6-5qdbk                        1/1     Running            1          13h
openebs       pod/openebs-admission-server-7b897bfcdc-l5pzn      1/1     Running            0          14m
openebs       pod/openebs-ndm-nzg44                              1/1     Running            2          14m
openebs       pod/openebs-ndm-operator-76d8945d4-h4ktq           1/1     Running            4          14m
openebs       pod/openebs-provisioner-64cd65d58f-v6nwn           1/1     Running            5          14m
openebs       pod/openebs-ndm-559ww                              1/1     Running            3          14m
openebs       pod/openebs-localpv-provisioner-6f7cd99684-hq79b   1/1     Running            3          14m
openebs       pod/maya-apiserver-5d9f6f96db-l7bqb                0/1     CrashLoopBackOff   9          14m

NAMESPACE     NAME                             TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)                  AGE
default       service/kubernetes               ClusterIP   10.43.0.1      <none>        443/TCP                  13h
kube-system   service/kube-dns                 ClusterIP   10.43.0.10     <none>        53/UDP,53/TCP,9153/TCP   13h
openebs       service/maya-apiserver-service   ClusterIP   10.43.12.24    <none>        5656/TCP                 14m
openebs       service/admission-server-svc     ClusterIP   10.43.24.191   <none>        443/TCP                  9m55s

NAMESPACE   NAME                         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
openebs     daemonset.apps/openebs-ndm   3         3         3       3            3           <none>          14m

NAMESPACE     NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/coredns                       1/1     1            1           13h
openebs       deployment.apps/openebs-admission-server      1/1     1            1           14m
openebs       deployment.apps/openebs-snapshot-operator     1/1     1            1           14m
openebs       deployment.apps/openebs-ndm-operator          1/1     1            1           14m
openebs       deployment.apps/openebs-provisioner           1/1     1            1           14m
openebs       deployment.apps/openebs-localpv-provisioner   1/1     1            1           14m
openebs       deployment.apps/maya-apiserver                0/1     1            0           14m

NAMESPACE     NAME                                                     DESIRED   CURRENT   READY   AGE
kube-system   replicaset.apps/coredns-8655855d6                        1         1         1       13h
openebs       replicaset.apps/maya-apiserver-5d9f6f96db                1         1         0       14m
openebs       replicaset.apps/openebs-admission-server-7b897bfcdc      1         1         1       14m
openebs       replicaset.apps/openebs-snapshot-operator-546b77dc67     1         1         1       14m
openebs       replicaset.apps/openebs-ndm-operator-76d8945d4           1         1         1       14m
openebs       replicaset.apps/openebs-provisioner-64cd65d58f           1         1         1       14m
openebs       replicaset.apps/openebs-localpv-provisioner-6f7cd99684   1         1         1       14m

I get a :

pi@pi1:~ $ kubectl logs pod/maya-apiserver-5d9f6f96db-l7bqb -n openebs
standard_init_linux.go:211: exec user process caused "exec format error"

And description of the pod gives :

pi@pi1:~ $ kubectl describe pod/maya-apiserver-5d9f6f96db-l7bqb -n openebs
Name:         maya-apiserver-5d9f6f96db-l7bqb
Namespace:    openebs
Priority:     0
Node:         pi2/192.168.2.40
Start Time:   Tue, 26 May 2020 11:41:25 +0200
Labels:       name=maya-apiserver
              openebs.io/component-name=maya-apiserver
              openebs.io/version=1.10.0
              pod-template-hash=5d9f6f96db
Annotations:  <none>
Status:       Running
IP:           10.42.1.5
IPs:
  IP:           10.42.1.5
Controlled By:  ReplicaSet/maya-apiserver-5d9f6f96db
Containers:
  maya-apiserver:
    Container ID:   containerd://c6397012b008f3439dc341091a3fa04dc3019d192bcbb6b6d333831e7518a43f
    Image:          quay.io/openebs/m-apiserver:1.10.0
    Image ID:       quay.io/openebs/m-apiserver@sha256:332bb8af16797ee017ef707b007e094dc799c02d69c1363194ccc9d7d3b8d667
    Port:           5656/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Tue, 26 May 2020 11:56:51 +0200
      Finished:     Tue, 26 May 2020 11:56:51 +0200
    Ready:          False
    Restart Count:  10
    Liveness:       exec [/usr/local/bin/mayactl version] delay=30s timeout=1s period=60s #success=1 #failure=3
    Readiness:      exec [/usr/local/bin/mayactl version] delay=30s timeout=1s period=60s #success=1 #failure=3
    Environment:
      OPENEBS_NAMESPACE:                             openebs (v1:metadata.namespace)
      OPENEBS_SERVICE_ACCOUNT:                        (v1:spec.serviceAccountName)
      OPENEBS_MAYA_POD_NAME:                         maya-apiserver-5d9f6f96db-l7bqb (v1:metadata.name)
      OPENEBS_IO_CREATE_DEFAULT_STORAGE_CONFIG:      true
      OPENEBS_IO_INSTALL_DEFAULT_CSTOR_SPARSE_POOL:  false
      OPENEBS_IO_JIVA_CONTROLLER_IMAGE:              quay.io/openebs/jiva-arm64:1.10.0
      OPENEBS_IO_JIVA_REPLICA_IMAGE:                 quay.io/openebs/jiva-arm64:1.10.0
      OPENEBS_IO_JIVA_REPLICA_COUNT:                 3
      OPENEBS_IO_CSTOR_TARGET_IMAGE:                 quay.io/openebs/cstor-istgt-arm64:1.10.0
      OPENEBS_IO_CSTOR_POOL_IMAGE:                   quay.io/openebs/cstor-pool-arm64:1.10.0
      OPENEBS_IO_CSTOR_POOL_MGMT_IMAGE:              quay.io/openebs/cstor-pool-mgmt-arm64:1.10.0
      OPENEBS_IO_CSTOR_VOLUME_MGMT_IMAGE:            quay.io/openebs/cstor-volume-mgmt-arm64:1.10.0
      OPENEBS_IO_VOLUME_MONITOR_IMAGE:               quay.io/openebs/m-exporter-arm64:1.10.0
      OPENEBS_IO_CSTOR_POOL_EXPORTER_IMAGE:          quay.io/openebs/m-exporter-arm64:1.10.0
      OPENEBS_IO_HELPER_IMAGE:                       quay.io/openebs/linux-utils-arm64:1.10.0
      OPENEBS_IO_ENABLE_ANALYTICS:                   true
      OPENEBS_IO_INSTALLER_TYPE:                     openebs-operator-arm
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from openebs-maya-operator-token-x5z9k (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  openebs-maya-operator-token-x5z9k:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  openebs-maya-operator-token-x5z9k
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason                  Age                  From               Message
  ----     ------                  ----                 ----               -------
  Normal   Scheduled               <unknown>            default-scheduler  Successfully assigned openebs/maya-apiserver-5d9f6f96db-l7bqb to pi2
  Normal   Pulling                 15m                  kubelet, pi2       Pulling image "quay.io/openebs/m-apiserver:1.10.0"
  Normal   Pulled                  15m                  kubelet, pi2       Container image "quay.io/openebs/m-apiserver:1.10.0" already present on machine
  Normal   Created                 15m (x2 over 15m)    kubelet, pi2       Created container maya-apiserver
  Normal   Started                 15m (x2 over 15m)    kubelet, pi2       Started container maya-apiserver
  Warning  BackOff                 15m (x2 over 15m)    kubelet, pi2       Back-off restarting failed container
  Warning  FailedCreatePodSandBox  13m                  kubelet, pi2       Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "a4ba7f5c20f14aa6c18df53bf43fa5e47fcd0604125a48f31a9bff70392264dc": open /run/flannel/subnet.env: no such file or directory
  Normal   SandboxChanged          13m (x2 over 13m)    kubelet, pi2       Pod sandbox changed, it will be killed and re-created.
  Normal   Pulled                  9m56s (x4 over 13m)  kubelet, pi2       Container image "quay.io/openebs/m-apiserver:1.10.0" already present on machine
  Normal   Created                 9m56s (x4 over 13m)  kubelet, pi2       Created container maya-apiserver
  Normal   Started                 9m56s (x4 over 13m)  kubelet, pi2       Started container maya-apiserver
  Warning  BackOff                 80s (x48 over 11m)   kubelet, pi2       Back-off restarting failed container
pi@pi1:~ $ 

Can you help me ?
It seems that a sandbox pod is not able to run correctly, don't know why

@vielmetti
Copy link

@vielmetti vielmetti commented May 26, 2020

"exec format error" is usually a signal that the binary in a container is for the wrong architecture, which in turn is usually a signal that the container in the registry does not have multiarch support.

quay.io/openebs/m-apiserver:1.10.0

Looking at

https://github.com/openebs/maya/blob/master/buildscripts/apiserver/Makefile.mk

it appears that the arm64 binaries are in a separate container in the registry. Quay for the longest time did not have arm64 support, but now it does.

@vielmetti
Copy link

@vielmetti vielmetti commented May 26, 2020

the latest touch in that repo was from @kmova - are there any technical blockers to making a single multiarch image for m-apiserver that would include both arm64 and amd64 files?

@armandleopold
Copy link

@armandleopold armandleopold commented May 26, 2020

Thanks it works !
Editing :

        image: quay.io/openebs/m-apiserver:1.10.0

To

        image: quay.io/openebs/m-apiserver-arm64:1.10.0

@kmova
Copy link
Member

@kmova kmova commented May 27, 2020

@vielmetti @armandleopold - the multi-arch support is under development. One challenge we have currently is with managing the dependencies on the CGO / gcc for some components like NDM. The development is being tracked under: #3023

@xUnholy is currently helping to sort this out. openebs/node-disk-manager#428

@akhilerm
Copy link
Member

@akhilerm akhilerm commented May 30, 2020

@armandleopold The fix for maya apiserver arm image is taken in this PR

@Halytskyi
Copy link

@Halytskyi Halytskyi commented Jun 3, 2020

I have multi-arch k8s cluster.
2 nodes amd64 and 4 nodes arm64.
In deployment I can choose only one architecture, therefore, have issue with openebs on other arch.
For example, when I use "local pv hostpath" and "openebs-localpv-provisioner" deployed on amd64, it's not working on arm64 device as "linux-utils" defined for amd64:

Normal  Pulled     25s   kubelet, worker02  Container image "quay.io/openebs/linux-utils@sha256:c43eda3de479248100c85b37b123bb405226185003fe7f57c1011ccb46def110" already present on machine
...
init-pvc-42ade16b-92e3-4048-9fae-cfad0ca7e317                     0/1     Error               0          3s      10.174.0.1   worker02   <none>           <none>
...
➜  ~ kubectl logs init-pvc-42ade16b-92e3-4048-9fae-cfad0ca7e317 -n openebs
standard_init_linux.go:211: exec user process caused "exec format error"

Any way to deploy OpenEBS on multi-arch cluster now or need wait for multi-arch containers?
Any ETA? Thanks.

@kmova kmova moved this from Pre-commits and Designs - Due: May 31 2020 to Pushed to Next release due to WIP in 1.11 Release Tracker - Due June 15th. Jun 3, 2020
@kmova kmova moved this from Pushed to Next release due to WIP to Release Items in 1.11 Release Tracker - Due June 15th. Jun 3, 2020
kmova added a commit to kmova/openebs that referenced this issue Jul 15, 2020
Refer: [GOVERNANCE.md](https://github.com/openebs/openebs/blob/master/GOVERNANCE.md).

The following community members have been helping with enhancing and testing
of several areas of the OpenEBS project that broadly fall in the purview of the
control plane.

Based on their past contributions and their interest/commitment to contributing
to OpenEBS, we take pride in adding them as reviewers to the OpenEBS project.

The list of community members in alphabetical order are:

- Mehran Kholdi for the contributions to the Local PV and control plane in general.
  ```
  - openebs#2975
  - 40+ commits in https://github.com/openebs/rawfile-localpv
  ```

- Michael Fornaro for the contributions to the ARM, Multi-arch builds and helm charts that fall under control plane.
  ```
  - openebs/e2e-tests#405
  - openebs#3038
  - openebs#3023
  - openebs#3037
  - openebs#1295
  - openebs/linux-utils#5
  - openebs/node-disk-manager#446
  - openebs/node-disk-manager#449
  - openebs/node-disk-manager#428
  ```

- Peeyush Gupta for the contributions to the Power builds and control plane in general.
  ```
  - openebs/charts#127
  - openebs/node-disk-manager#448
  - openebs/maya#1632
  - openebs/jiva#279
  - openebs/maya#667
  - openebs/istgt#131
  - openebs/maya#561
  - openebs/maya#750
  ```

Signed-off-by: kmova <kiran.mova@mayadata.io>
kmova added a commit that referenced this issue Jul 15, 2020
Refer: [GOVERNANCE.md](https://github.com/openebs/openebs/blob/master/GOVERNANCE.md).

The following community members have been helping with enhancing and testing
of several areas of the OpenEBS project that broadly fall in the purview of the
control plane.

Based on their past contributions and their interest/commitment to contributing
to OpenEBS, we take pride in adding them as reviewers to the OpenEBS project.

The list of community members in alphabetical order are:

- Mehran Kholdi for the contributions to the Local PV and control plane in general.
  ```
  - #2975
  - 40+ commits in https://github.com/openebs/rawfile-localpv
  ```

- Michael Fornaro for the contributions to the ARM, Multi-arch builds and helm charts that fall under control plane.
  ```
  - openebs/e2e-tests#405
  - #3038
  - #3023
  - #3037
  - #1295
  - openebs/linux-utils#5
  - openebs/node-disk-manager#446
  - openebs/node-disk-manager#449
  - openebs/node-disk-manager#428
  ```

- Peeyush Gupta for the contributions to the Power builds and control plane in general.
  ```
  - openebs/charts#127
  - openebs/node-disk-manager#448
  - openebs/maya#1632
  - openebs/jiva#279
  - openebs/maya#667
  - openebs/istgt#131
  - openebs/maya#561
  - openebs/maya#750
  ```

Signed-off-by: kmova <kiran.mova@mayadata.io>
@github-actions
Copy link

@github-actions github-actions bot commented Sep 2, 2020

Issues go stale after 90d of inactivity.

@vielmetti
Copy link

@vielmetti vielmetti commented Sep 2, 2020

Bumping this issue which has gone stale, but @kmova has some earlier work on e2e pipelines for testing at openebs/e2e-tests#405 which should be of interest.

@github-actions github-actions bot closed this Sep 10, 2020
1.11 Release Tracker - Due June 15th. automation moved this from Release Items to Done Sep 10, 2020
@akhilerm akhilerm reopened this Sep 10, 2020
Akshay-Nagle added a commit to Akshay-Nagle/openebs that referenced this issue Oct 7, 2020
Refer: [GOVERNANCE.md](https://github.com/openebs/openebs/blob/master/GOVERNANCE.md).

The following community members have been helping with enhancing and testing
of several areas of the OpenEBS project that broadly fall in the purview of the
control plane.

Based on their past contributions and their interest/commitment to contributing
to OpenEBS, we take pride in adding them as reviewers to the OpenEBS project.

The list of community members in alphabetical order are:

- Mehran Kholdi for the contributions to the Local PV and control plane in general.
  ```
  - openebs#2975
  - 40+ commits in https://github.com/openebs/rawfile-localpv
  ```

- Michael Fornaro for the contributions to the ARM, Multi-arch builds and helm charts that fall under control plane.
  ```
  - openebs/e2e-tests#405
  - openebs#3038
  - openebs#3023
  - openebs#3037
  - openebs#1295
  - openebs/linux-utils#5
  - openebs/node-disk-manager#446
  - openebs/node-disk-manager#449
  - openebs/node-disk-manager#428
  ```

- Peeyush Gupta for the contributions to the Power builds and control plane in general.
  ```
  - openebs/charts#127
  - openebs/node-disk-manager#448
  - openebs/maya#1632
  - openebs/jiva#279
  - openebs/maya#667
  - openebs/istgt#131
  - openebs/maya#561
  - openebs/maya#750
  ```

Signed-off-by: kmova <kiran.mova@mayadata.io>
Signed-off-by: Kung Fu Panda <akshay_1901cb06@iitp.ac.in>
@github-actions
Copy link

@github-actions github-actions bot commented Dec 10, 2020

Issues go stale after 90d of inactivity.

@akhilerm
Copy link
Member

@akhilerm akhilerm commented Dec 10, 2020

@kmova @nsathyaseelan Are there updates on the e2e pipelines for ARM.?

@nderraugh
Copy link

@nderraugh nderraugh commented Dec 30, 2020

Will this work also cover multi-arch for https://github.com/openebs/cstor-operators as well? Currently seeing the exec format error messages for openebs-cstor-csi-controller, and openebs-csi-node after installing with kubectl apply -f https://openebs.github.io/charts/cstor-operator.yaml on an ARM64 cluster.

@github-actions
Copy link

@github-actions github-actions bot commented Mar 31, 2021

Issues go stale after 90d of inactivity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
1.10 Release Tracker - Due May 15th.
  
Pushed to Next release due to WIP
1.9 Release Tracker - Due Apr 15th.
  
Pushed to Next release due to WIP
Linked pull requests

Successfully merging a pull request may close this issue.

None yet