[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
Mon, 7 Sep 2020 12:37:29 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
On 9/7/20 12:28 PM, Daniel P. Berrangé wrote:
> On Mon, Sep 07, 2020 at 11:59:18AM +0200, Philippe Mathieu-Daudé wrote:
>> 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):
> Well that looks better than what is done for the JEOS images currently
> on avocado-project.org, as I can't tell what distro those came from
> at all.
> If we're hosting images built by some 3rd party, and we intend to rely
> on the 3rd party to satisfy source availability, then we need to be sure
> that the 3rd party is themselves still distributing the same images.
> IIUC, from Cleber's commit here the original images we're pointing to
> are now 404s. If the URLs moved, we just need to update to fix the URLs
> to point the new location. If the content was entirely removed though,
> we shouldn't mirror it ourselves, because we can't rely on the original
> vendor to be providing the source at that point.
Having backups and the SHA1 of the files already commited in our
repository, this is the outcome I prefer.
Let see what other think on this topic.
Thanks for your insights :)
[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