Re: [Qemu-devel] Publishing binary images for testing (was Re: [RFC PATCH 0/6] generic way to deprecate machines)

[Alistair Francis]

On Tue, May 22, 2018 at 9:17 AM, Cleber Rosa <address@hidden> wrote:
>
>
> On 05/18/2018 02:16 PM, Alistair Francis wrote:
>> On Fri, May 11, 2018 at 7:27 AM, Cleber Rosa <address@hidden> wrote:
>>>
>>>
>>> On 05/11/2018 09:55 AM, Eduardo Habkost wrote:
>>>> (CCing Cleber and avocado-devel in case they have suggestions)
>>>>
>>>> On Tue, May 08, 2018 at 12:47:52PM -0300, Philippe Mathieu-Daudé wrote:
>>>> [...]
>>>>> Ironically I have been using the Gumstix machines quite a lot for the SD
>>>>> 'subsystem' refactor, using the MMC commands in U-Boot (I am unable to
>>>>> reach the Linux userland since the kernel crashes), and plan to add SD
>>>>> integration tests via Avocado.
>>>>>
>>>>> This raises:
>>>>>
>>>>> - What will happens if I add tests downloading running on their compiled
>>>>> u-boot
>>>>> (https://downloads.gumstix.com/images/angstrom/developer/2012-01-22-1750/u-boot.bin)
>>>>> and the company decides to remove this old directory?
>>>>> Since sometimes old open-source software are hard to rebuild with recent
>>>>> compilers, should we consider to use a public storage to keep
>>>>> open-source (signed) blobs we can use for integration testing?
>>>>
>>>> I think a maintained repository of images for testing would be
>>>> nice to have.  We need to be careful to comply with the license
>>>> of the software being distributed, though.
>>>>
>>>> If the images are very small (like u-boot.bin above), it might be
>>>> OK to carry them in qemu.git, just like the images in pc-bios.
>>>>
>>>>>
>>>>> Avocado has a 'vmimage library' which could be extended, adding support
>>>>> for binary url + detached gpg signatures from some QEMU maintainers?
>>>>
>>>> Requiring a signature makes the binaries hard to replace.  Any
>>>> specific reason to suggest gpg signatures instead of just a
>>>> (e.g.) sha256 hash?
>>>>
>>>>>
>>>>> (I am also using old Gentoo/Debian packaged HPPA/Alpha Linux kernel for
>>>>> Avocado SuperIO tests, which aren't guaranteed to stay downloadable
>>>>> forever).
>>>>
>>>> Question for the Avocado folks: how this is normally handled in
>>>> avocado/avocado-vt?  Do you maintain a repository for guest
>>>> images, or you always point to their original sources?
>>>>
>>>
>>> For pure Avocado, the vmimage library attempts to fetch, by default, the
>>> latest version of a guest image directly from the original sources.
>>> Say, a Fedora image will be downloaded by default from the Fedora
>>> servers.  Because of that, we don't pay too much attention to the
>>> availability of specific (old?) versions of guest images.
>>>
>>> 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/
>>
>> Is it possible to add something to the landing page at
>> https://avocado-project.org ?
>>
>
> Done!

Awesome! It looks good and this should help everyone behind a proxy.

Alistair

> - Cleber.
>
>> The Palo Alto Network routers block the avocado-project.org page as
>> they classify it as blank. Something on the root URL would help fix
>> this.
>>
>> Alistair
>>