[
https://issues.apache.org/jira/browse/KUDU-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16994548#comment-16994548
]
liusheng commented on KUDU-3007:
--------------------------------
Hi Adar Dembo,
Thanks for your detailed explanation. according to your description, it is
seems not easy job to integrate an ARM CI to Kudu than what I thought I am a
new comer to Kudu community, will take a look about the dist-test framework,
but I cannot open the kudu-upstream-infra repo(maybe it is a private repo of
Cloudera). I am also learning about how to build and run the tests privately.
The first step is to make the building process sucessfully on ARM server.
About how to integrate aarch64 resources, here are some thoughts from me:
About the resources donating, it is doesn't matter, we can donate ARM resource
separatly to Clouder infra beside ASF's infra donating at any time, and if you
would like to help to do some early attempts, please let me know, I am pleasure
to provide an ARM VM with specific vCPUs, Mem, Disk you need.
According to your description, I also think that it is not easy to integrate
ARM resources with GCP's VMs in a dist-test cluster, not sure but maybe it is
also not easy to host a second dist-test deployment in our ARM resources pool.
And as your said, running tests without dist-test is also not a good way of
pre-commit triggering.
I am also agree with your suggested approach of a separate Jenkins job in
jenkins.kudu.apache.org. recently, we have also finished a periodic CI of
aarch64 testing for Hadoop using this way, see
[here|https://builds.apache.org/view/H-L/view/Hadoop/job/Hadoop-qbt-linux-ARM-trunk/]
This way looks like no effect on current community development, and convenient
to present the testing results in a common place.
OpenLab CI was built by [Zuul|https://zuul-ci.org/] which is developed by
OpenStack Infra and used as the OpenStack community CI, OpenStack communty also
use Gerrit as [review dashboard|https://review.opendev.org/#/q/status:open]. So
OpenLab CI naturally support Gerrit integration. OpenLab CI support defining
periodic job or job triggered by commit. For pre-commit job, it can publish
testing results to commits' comment as it is now. and job can be defined
'no-voting', which means the +1/-1 testing result won't block commits merging.
As you mentioned, if we use OpenLab CI to build a job without dist-test, the
may running in a long time, so seems it is not proper to be a pre-commit job.
If we define a separate periodic job in OpenLab CI it is easy to be implemented
in OpenLab, the testing results can be found in OpenLab's
[dashboard|https://status.openlabtesting.org/builds], but seems there isn't a
good way to present the results in Kudu community.
Summarily, I would prefer the approach of a separate Jenkins job in
jenkins.kudu.apache.org, how do you think ?
Thanks in advance.
> ARM/aarch64 platform support
> ----------------------------
>
> Key: KUDU-3007
> URL: https://issues.apache.org/jira/browse/KUDU-3007
> Project: Kudu
> Issue Type: Improvement
> Reporter: liusheng
> Priority: Critical
>
> As an import alternative of x86 architecture, Aarch64(ARM) architecture is
> currently the dominate architecture in small devices like phone, IOT devices,
> security cameras, drones etc. And also, there are more and more hadware or
> cloud vendor start to provide ARM resources, such as AWS, Huawei, Packet,
> Ampere. etc. Usually, the ARM servers are low cost and more cheap than x86
> servers, and now more and more ARM servers have comparative performance with
> x86 servers, and even more efficient in some areas.
> We want to propose to add an Aarch64 CI for KUDU to promote the support for
> KUDU on Aarch64 platforms. We are willing to provide machines to the current
> CI system and manpower to mananging the CI and fxing problems that occours.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
