Re: [PATCH 0/2] Allwinner H3 fixes for EMAC and acceptance tests

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

Hi Niek,

On 2/17/21 9:57 PM, Niek Linnenbank wrote:
> Hi Daniel, Philippe,
> 
> Op di 16 feb. 2021 10:49 schreef Daniel P. Berrangé <berrange@redhat.com
> <mailto:berrange@redhat.com>>:
> 
>     On Fri, Feb 12, 2021 at 03:10:00PM +0100, Philippe Mathieu-Daudé wrote:
>     > Hi Niek and QEMU community,
>     >
>     > On 2/11/21 11:00 PM, Niek Linnenbank wrote:
>     > > The following are maintenance patches for the Allwinner H3. The
>     first patch
>     > > is a proposal to relocate the binary artifacts of the acceptance
>     tests away
>     > > from the apt.armbian.com <http://apt.armbian.com> domain. In the
>     past we had problems with artifacts being
>     > > removed, and now the recently added Armbian 20.08.1 image has
>     been removed as well:
>     > >
>     > > $ wget
>     https://dl.armbian.com/orangepipc/archive/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz
>     <https://dl.armbian.com/orangepipc/archive/Armbian_20.08.1_Orangepipc_bionic_current_5.8.5.img.xz>
>     > > Connecting to dl.armbian.com <http://dl.armbian.com>
>     (dl.armbian.com <http://dl.armbian.com>)|2605:7900:20::5|:443...
>     connected.
>     > > ...
>     > > HTTP request sent, awaiting response... 404 Not Found
>     > > 2021-02-11 22:34:45 ERROR 404: Not Found.
>     > >
>     > > I've now added the artifacts to a server maintained by me. The
>     machine has a stable
>     > > uptime of several years, ~100Mbit bandwidth and plenty of
>     available storage.
>     > > Also for other artifacts if needed. I'm open to discuss if there
>     is a proposal
>     > > for a better location for these artifacts or a more generic qemu
>     location.
>     >
>     > Thanks for trying to fix this long standing problem.
>     >
>     > While this works in your case, this doesn't scale to the community,
>     > as not all contributors have access to such hardware and bandwidth /
>     > storage.
>     >
>     > While your first patch is useful in showing where the artifacts are
>     > stored doesn't matter - as long as we use cryptographic hashes - I
>     > think it is a step in the wrong direction, so I am not keen on
>     > accepting it.
>     >
>     > My personal view is that any contributor should have the same
>     > possibilities to add tests to the project. Now I am also open to
>     > discuss with the others :) I might be proven wrong, and it could
>     > be better to rely on good willing contributors rather than having
>     > nothing useful at all.
> 
>     There aren't many options here
> 
>      1. Rely on a vendor to provide stable download URLs for images
> 
>      2. QEMU host all images we use in testing
> 
>      3. Contributor finds some site to upload images to
> 
> 
>     For the armbian images we rely on (1), but the URLs didn't turn out
>     to be
>     stable. In fact no OS vendor seems to have guaranteed stable URLs
>     forever,
>     regardless of distro, though most eventually do have an archive site
>     that
>     has good life. Armbian was an exception in this respect IIUC.
> 
>     (2) would solve the long term stability problem as QEMU would be in full
>     control, and could open it up for any images we need. The big challenge
>     there is that QEMU now owns the license compliance problem. Merely
>     uploading
>     binary images/packages without the corresponding source is generally
>     a license
>     violation. QEMU could provide hosting, but we need to be clear about
>     the fact
>     that we now own the license compliance problem ourselves. Many sites
>     hosting
>     images simply ignore this problem, but that doesn't make it right.
> 
> 
>     This series is proposing (3), with a site the contributor happens to
>     control
>     themselves, but using a free 3rd party hosting site is no different
>     really.
>     Again there is a the same need for license compliance, but it is now the
>     responsibility of the user, not QEMU project.
> 
>     In this http://www.freenos.org/pub/qemu/cubieboard/
>     <http://www.freenos.org/pub/qemu/cubieboard/> site I can't even see a
>     directory listing, so even if corresponding source does exist in
>     this server,
>     I can't find it.
> 
>     The isn't really a problem for QEMU CI to consume the images, but as
>     a free
>     software developer I don't like encouraging practices that are not
>     compliant
>     with licensing reuqirement.
> 
>     It is an open question whether the (3) is really better than (1) in
>     terms
>     of URL stability long term, especially if running off a user's personal
>     server.
> 
> 
> I understand your concerns. My goal here was to be able to re-activate
> the orangepi tests, so we can capture bugs early on.

I hope you understand the concern I have is not with you in particular,
and I used your case to start a discussion with the QEMU community.

FWIW I missed the URL change because I still have the image cached in
Avocado so my testing ran fine. Which makes me wonder...

Cleber, Willian, should Avocado display information about cached
artifacts? Such "Using artifact downloaded 7 months ago".

> So what I can do
> instead is:
> 
>   - update the patch to use github to store the artifacts, and their
> licenses (other tests also use github)

Until there is better solutions, this is the option I prefer.

>   - or change the patch to use updated armbian links that work (for now)
> 
> If we can agree on either of these solutions, so the orangepi tests can
> be re-activated, that would be great. 
> 
> Kind regards,
> Niek