Hi Yinsi,
It's my pleasure to meet you. Please see my comments in line.
On Sun, Jan 17, 2021 at 12:36 AM Jammy Zhou jammy.zhou@linaro.org wrote:
Hi Yinsi,
Per my understanding, please check some comments inline:
On Thu, 14 Jan 2021 at 18:47, Jonathan Cameron < jonathan.cameron@huawei.com> wrote:
Something slightly strange happened with Anmar’s email address. To make sure he got this I’ve added him again.
Thanks.
Jonathan
*From:* liuyinsi@163.com [mailto:liuyinsi@163.com] *Sent:* 14 January 2021 10:25 *To:* mailto@ <anmar.oueja "mailto:anmar.oueja"@linaro.org> *Cc:* lkq-dev lkq-dev@op-lists.linaro.org; jammy.zhou@linaro.org; Jonathan Cameron jonathan.cameron@huawei.com; wufengguang < wufengguang@huawei.com> *Subject:* Re: Fwd: Remote LKFT dispatcher
Hello anmar,
It's nice to meet you too. I have some questions and need your help.
- Should i install OpenEuler system in ARM or hard disk?
I think you're expected to install openEuler OS on one Kunpeng server
- Could you provide LKFT deploy script?
According to Anmar's proposal, please complete the tasks below first:
- setup and configure a dedicated Huawei server for remote access
- install and configure openEuler on the machine
I leave it up to you to decide which version of OpenEuler you wish to install but I advise you go with the LTS one because this machine will eventually move into our production instance so we want to maximize stability.
- grant specific Linaro individuals access to the server with Sudo
permissions (dispatcher container requires root access)
I see you sent me another email with the details, which I will respond to directly.
And then Linaro will do the following tasks:
- install and configure a remote dispatcher that will be registered in the
LKFT master instance
- initially use the server in its staging instance to allow issues be
identified and resolved before moving it to the production instance
- move the server to LKFT's production instance
Indeed. The dispatcher is packaged using Docker. I'm aware of iSula (a docker alternative from the OpenEuler project). However, I like to avoid using it at this point in an effort to minimize any external variables.
Hope it's more clear to you.
- Our server maybe power off in some special cases, how long do i have
to tell you in advance?
Before the server is moved to production instance, I think it can be flexible. And we can discuss the maintaining of the server later.
Indeed! Let's cross that bridge when we get to it.
Anmar, please correct if I'm wrong.
All is good :-)
Thanks, anmar
*From:* wufengguang wufengguang@huawei.com
*Date:* 2021-01-13 18:50
*To:* liuyinsi@163.com
*Subject:* Fwd: Remote LKFT dispatcher
*发件人**:* Anmar Oueja [mailto:anmar.oueja@linaro.org anmar.oueja@linaro.org] *发送时间**:* 2021年1月12日 10:20 *收件人**:* wufengguang wufengguang@huawei.com *抄送**:* lkq-dev@op-lists.linaro.org; Jammy Zhou jammy.zhou@linaro.org; Jonathan Cameron jonathan.cameron@huawei.com; Guohanjun (Hanjun Guo) < guohanjun@huawei.com> *主题**:* Remote LKFT dispatcher
Hello Fengguang,
I hope this email finds you well. I discussed the details of using one of your servers as a remote instance for KVM Qemu DUTs and it seems pretty straightforward. Here is a brief proposal to things rolling. Feedback is welcome.
Goals
- Expand LKFT's Aarch64 test capacity using KVM Qemu using Huawei server
as a host system.
- Provide a real workload to test of OpenEuler OS by using it as a host
OS to host the Qemu KVM instances
Deliverables
- OpenEuler to setup and configure a dedicated Huawei server for remote
access
OpenEuler to Install and configure its OS on the machine
OpenEuler to grant specific Linaro individuals access to the
server with Sudo permissions (dispatcher container requires root access)
- Linaro will install and configure a remote dispatcher that will be
registered in the LKFT master instance
- Linaro will initially use the server in its staging instance to allow
issues be identified and resolved before moving it to the production instance
- Linaro to move the server to LKFT's production instance
Assumptions
- OpenEuler community will administer the server and maintain it
including keeping up with the dispatcher monthly updates (as part of LAVA's monthly releases)
- Adequate storage and memory are provided to maximise the number of
simultaneous Qemu instances
- Network bandwidth is fast enough to download all the images and test
artifacts needed to run the tests and report the results in a timely fashion
Risks
- Once the server is moved to the production instance of LKFT, uptime
commitments from the OpenEuler project will be required. This can be discussed at a later date.
Thanks,
anmar