[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/4] Acceptance tests: use an available kernel image package
Re: [PATCH 1/4] Acceptance tests: use an available kernel image package for arm
Tue, 8 Sep 2020 15:47:35 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
On 9/8/20 3:20 PM, Alex Bennée wrote:
> Philippe Mathieu-Daudé <email@example.com> writes:
>> On 9/7/20 11:39 AM, Daniel P. Berrangé wrote:
>>> On Mon, Sep 07, 2020 at 10:06:13AM +0200, Philippe Mathieu-Daudé wrote:
>>>> [Cc'ing Daniel who usually have good ideas for that
>>>> kind if project-wide problem]
>>>> On 9/7/20 6:19 AM, Cleber Rosa wrote:
>>>>> Which means a newer kernel version. Expected output was changed
>>>>> to match the new kernel too.
>>>> Acceptance tests are not to test the latest Linux kernel,
>>>> they aim to assert a specific kernel tested by some developer
>>>> still works while QEMU evolves.
>>>> QEMU doesn't have to adapt to the latest kernel;
>>>> QEMU should keep boot an old kernel.
>>>> Testing new kernels is good, you are adding coverage. But
>>>> this break the acceptance testing contract "keep testing
>>>> the same thing over time".
>>>> The problem you are trying to fix is the "where to keep
>>>> assets from public locations where they are being removed?"
>>>> one. Two years ago [*] you suggested to use some storage on
>>>> the avocado-project.org:
>>>> For Avocado-VT, there are the JeOS images, which we
>>>> keep on a test "assets" directory. We have a lot of
>>>> storage/bandwidth availability, so it can be used for
>>>> other assets proven to be necessary for tests.
>>>> As long as distribution rights and licensing are not
>>>> issues, we can definitely use the same server for kernels,
>>>> u-boot images and what not.
>>>>  - https://avocado-project.org/data/assets/
>>> If I look at stuff under that directory I see a bunch of "Jeos" qcow2
>>> images, and zero information about the corresponding source for the
>>> images, nor any information about the licenses of software included.
>>> IOW what is stored their right now does not appear to comply with the
>>> GPL licensing requirements for providing full and corresponding source.
>>>> It is time to have QEMU assets managed the same way.
>>> I'd rather we didn't do anything relying on binary blobs with no
>>> info about how they were built. Pointing to the 3rd party download
>>> URLs was the easy way to ensure we don't have to worry about licensing
>> I tried to be very strict including the recipe about how to rebuild
>> and description of the source (for licensing) in each commits (Alex
>> Bennée once said Debian/Fedora based was OK):
> Debian and Fedora both have good project hygiene for tracking sources
> for their binary packages and extensive archives which we can work with.
> These other projects seem to be more of a moving feast which I think is
> proving we can't rely on them as a CI test and at best best efforts for
> developer testing.
> It seems Armbian do document their build process but it's not quite as
> easy as just downloading the source deb.
Should we remove the Armbian based tests? I don't have any problem,
as long as the requisites for adding a test are clearly documented
(as there are not obvious to all).
>>> IIUC, the majority of our acceptance tests needs should be satisfied
>>> with a combination of a Linux kernel and busybox tools. We already
>>> use cross-compilers to build TCG test cases.
>>> I'd like to see us provide a minimal "config" file for each Linux
>>> kernel combo we need to test. We should be able to define a fairly
>>> simple script that do the Linux build, busybox build and then puts
>>> the combination of them into a disk image. Something 100% automated
>>> and reviewable.
>> For Debian/Fedora this config is available in their package (or source
>>> Even a minimal linux build takes some time, so we would need to cache
>>> the binary result in some suitable manner. At least this way we have
>>> a clear record of what we're building & how and can thus satisfy the
>>> license rules.
>> Yes, but if the Debian/Fedora build farms already build/published
>> their packages, it is easier to use it directly.
>> QEMU developers are very reluctant to add tests. I suppose we prefer
>> to develop or fix bugs rather than write tests. If we ask full build
>> recipe for each tests, I doubt we'll have much testing.
> I've pondered this before and while it might have a place for random
> weird machines with no mainline distro support it's not a path I'm keen
> to go down. This goes especially for some of the more esoteric ARM
> hardware where you start relying on hacked up vendor trees with very
> specific toolchain requirements.
What I'd really like is to have the test logic in mainstream (not
the test artifacts). That way maintainers can "pass" their tests
when passing maintenance, or if one stop contributing, the tests
are still usable by anyone in the community.
Some closed-source binaries are available publicly, and we can
verify their hash.
Is it acceptable to add test + hash in mainstream, so any developer
in possession of such binaries is free to run the tests? There
should not be any licensing issue.
I would like to avoid "black box" devices we are afraid to modify
because very few people can test them.
Example of tests I'd like to add:
[PATCH 2/4] boot linux test: update arm bionic URL, Cleber Rosa, 2020/09/07
[PATCH 3/4] tests: bump avocado version, Cleber Rosa, 2020/09/07
[PATCH 4/4] Acceptance tests: cancel tests on missing assets, Cleber Rosa, 2020/09/07
Re: [PATCH 0/4] Acceptance Tests: update assets location and cancel tests if missing, Philippe Mathieu-Daudé, 2020/09/08