Hello Fengguang,
I hope this email finds you well. Since our call last week, we’ve been
working internally trying to best identify issues/questions we need to
draft up the scope of work for our collaboration with Compass CI and we
have the following points we wish to discuss with you further.
After some internal discussions, we think and support your proposal of
having Compass CI dispatch jobs to LAVA via the dispatcher. However, we did
have a few questions we need your help in answering:
Q1. Do you expect to use LKFT’s lab?
Q2. Do you want to add your embedded boards to your dispatcher in your own
lab?
Q3. We assume you want to test the OpenEuler kernel. Do you want to use our
OpenEmbedded or OpenEuler rootFS?
Q4. Do you want to run the same test we run in LKFT?
Q5. Do you want to run LKP tests
Q6. IF you wish to run Linaro test definitions, the data will be stored in
SQUAD. For LKP, we expect the tests themselves to send the test results to
Compass CI directly.
We spent a lot of time discussing how to best collaborate with Compass CI
to the benefit of Linaro's members and we believe bolstering benchmark
testing is a key value your team can help us deliver. The focus is on
benchmark test extraction, processing and comparison. The functionality we
seek is in LKP so your team’s help in extracting and genericising such
tooling so we can leverage it in LKFT and other test frameworks.
We can discuss the above points over email or setup a call if you like.
Thanks,
Anmar
Hello anmar,
I'm sorry I forgot to tell you my email is liuyinsi(a)163.com, please do not email to liuyinsi(a)huawei.com.
Thank you for providing me the QEMU's instance booting log, I'm sorry I still don't know how to reproduce the issues.
Hello David and Luca,
Which command did it report errors when it was executed?
Where did you execute the commands？In the server openEuler OS
that i setup for you, or run a container on the server, then execute commands in the container?
Could you help me to reappear question on tmux 'tm lys', it is convenient to locate the problem, thank you very much.
Thanks,
yinsi
liuyinsi(a)163.com
发件人： Anmar Oueja
发送日期： 2021年02月18日 02:43
收件人： liuyinsi
抄送人： Cameron，wufengguang，yuchuan，lkq-dev，Dave Pigott，Luca Di Stefano，Jammy Zhou
主题： Issues with docker on OpenEulerOS
Hello Yinsi/Yuchan,
Happy Lunar New Year!!!
David and Luca (on CC) are hitting a few bumps trying to get the QEMU
instances running in a docker container on the OpenEuler OS install
you setup for us. The QEMU instances are failing to boot from NFS.
Thinking it might be a permission problem, we confirmed that the
containers are run as root and SELinux is disabled yet the problem
persists. We did replicate the setup on a Debian Aarch64 system and it
worked so we suspect there's something in OpenEuler OS we haven't
configured correctly.
This is QEMU's instance booting log you:
https://lkft-staging.validation.linaro.org/scheduler/job/100307
Can you please work with David and Luca to try and figure this out.
Cheers!
anmar
We still have some work to do to fully enable the Kungpen worker. We need to set up local mirrors in China of snapshots and set up git and netrc redirects so that we get a reasonable bandwidth.
Chase and Jammy - how do we go about expediting this?
Thanks
Dave
> On 21 Apr 2021, at 10:32, wufengguang via Lkq-dev <lkq-dev(a)op-lists.linaro.org> wrote:
>
> Hi Anmar,
>
>> Hello Fengguang,
>>
>> I hope this email finds you well. Since our call last week, we’ve
>> been working internally trying to best identify issues/questions we
>> need to draft up the scope of work for our collaboration with Compass
>> CI and we have the following points we wish to discuss with you
>> further.
>>
>> After some internal discussions, we think and support your proposal of
>> having Compass CI dispatch jobs to LAVA via the dispatcher.
>
> Glad to hear that, thanks!
>
>> However, we did have a few questions we need your help in answering:
>
> OK. Let me try answering these questions in the context of
> "having Compass CI dispatch jobs to LAVA via the dispatcher".
>
>> Q1. Do you expect to use LKFT’s lab?
>
> Yes in the sense of reusing LKFT lab's current facilities and
> functionalities to test openEuler kernel.
>
> As for "Compass CI + LAVA dispatcher", we mainly care about implementing
> the functionality. You may freely choose the most convenient lab (or
> create an experimental instance) to use in the development and debug
> process.
>
>> Q2. Do you want to add your embedded boards to your dispatcher in your own lab?
>
> I suppose so, after implemented the functionality.
>
> During the development phase, the developer may try things out on his local side
> if that would be more efficient.
>
>> Q3. We assume you want to test the OpenEuler kernel. Do you want to use our OpenEmbedded or OpenEuler rootFS?
>
> Yes we'll test openEuler kernel.
>
> For rootFS, I guess whatever readily available (eg. OpenEmbedded) should
> be fine in the beginning. When the job conversion+execution flow works,
> we may go on to check how to deploy openEuler rootFS via LAVA for
> limited SUT types.
>
>> Q4. Do you want to run the same test we run in LKFT?
>
> LKP jobs are our priority. I tend to not list LKFT jobs in the goal of
> this CompassCI+LAVA integration project, to reduce unnecessary complexity.
>
>> Q5. Do you want to run LKP tests
>
> Yes. Submitting LKP jobs to LAVA controlled devices.
> Auto converting LKP job to LAVA job for execution.
>
>> Q6. IF you wish to run Linaro test definitions, the data will be stored in SQUAD.
>> For LKP, we expect the tests themselves to send the test results to Compass CI directly.
>
> OK, got it.
>
>> We spent a lot of time discussing how to best collaborate with Compass
>> CI to the benefit of Linaro's members and we believe bolstering
>> benchmark testing is a key value your team can help us deliver. The
>> focus is on benchmark test extraction, processing and comparison. The
>> functionality we seek is in LKP so your team’s help in extracting and
>> genericising such tooling so we can leverage it in LKFT and other test
>> frameworks.
>
> lkp-tests is designed to be reusable by other projects. It should
> relatively easy to reuse its code.
>
> compass-ci services all run in containers, which makes their build
> dependency clear.
>
> Though there may still be a ton of boring/messy works in trying to
> integrating different parts of lkp-tests/compass-ci to LKFT in order to
> create a complete solution.
>
> Another tough question is whether LKFT duplicate the code and evolve
> standalone, or reuse code in place while trying to modify
> various places of the code to work in a different situation.
>
> compass-ci grows on top of lkp-tests in the very beginning, which makes
> the development natural and simple.
>
> Thanks,
> Fengguang
> --
> Lkq-dev mailing list
> Lkq-dev(a)op-lists.linaro.org
> https://op-lists.linaro.org/mailman/listinfo/lkq-dev
Hey, Rémi!
On Tue, 30 Mar 2021 at 07:49, Remi Duraffort via Lkq-dev
<lkq-dev(a)op-lists.linaro.org> wrote:
> I'm tryin to boot test some of lkft x86_64 and i386 kernels using TuxTest.
> My main issue is that lkft kernels does not support virtio as a block
> device, making TuxTest life more difficult.
>
> Would it be possible to add support for virtio block devices?
Do you happen to know which configs it is that we need? We actually
carry a "Virtio" config fragment:
https://github.com/Linaro/meta-lkft/blob/sumo/recipes-kernel/linux/files/vi…
Here's a (torvalds/master) kernel that we built with that fragment:
https://builds.tuxbuild.com/1qRb2aF6PNl6c20JEDRfFB4RFMT/
Thanks and greetings!
Daniel Díaz
daniel.diaz(a)linaro.org
