Re: [PATCH 1/4] Acceptance tests: use an available kernel image package for arm

["Daniel P. Berrangé" <berrange@redhat.com>]

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.
> >>
> >> Nack.
> >>
> >> 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[1], 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.
> >>
> >>   [1] - 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
> > problems.
> 
> 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):

..snip...

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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|