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@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@op-lists.linaro.org https://op-lists.linaro.org/mailman/listinfo/lkq-dev