[Libosinfo] New virtio-win repo and isos

[Cole Robinson]

On 05/06/2015 09:57 AM, Zeeshan Ali (Khattak) wrote:
> On Tue, May 5, 2015 at 6:34 PM, Cole Robinson <crobinso at redhat.com> wrote:
>> On 05/05/2015 08:12 AM, Zeeshan Ali (Khattak) wrote:
>>> On Fri, May 1, 2015 at 11:37 PM, Cole Robinson <crobinso at redhat.com> wrote:
>>>> Hey all,
>>>
>>> Hi Cole,
>>>
>>>> Wanted to give a heads up about a new repo with virtio-win RPMs. Isos are
>>>> still available for direct download, just at a different URL. All the details
>>>> are here:
>>>>
>>>> https://fedoraproject.org/wiki/Windows_Virtio_Drivers
>>>>
>>>> FWIW the rpm and iso now match the layout of what we ship with RHEL, and match
>>>> the content (except still no WHQL signature).
>>>
>>> Thats really awesome. Thanks for working on this.
>>>
>>>> Not sure how interesting it is to libosinfo/boxes in its current form.
>>>> But
>>>> it's a fresh base to start from if you have any ideas or suggestions about how
>>>> to improve things in this area.
>>>
>>> Well it would be really good to have all drivers files available in
>>> unpacked form at a canonical location (than zeenix.fedorapeople.org).
>>> If you could make that happen, that would be very helpful. Currently I
>>> manually unpack the latest ISO and upload the driver files to my
>>> personal webspace and then update the libosinfo db. So a lot of manual
>>> work and I tend to forget about such tasks and hence the reason you'd
>>> find drivers we currently use in libosinfo are a bit old.
>>>
>>
>> So looks like the only drivers you need there are the virtio-block bits,
>> though we should probably expose virtio-scsi as well since it seems storage is
>> the only bit that's needed (virt-v2v has similar requirements though they get
>> the drivers from /usr/share via the virtio-win RPM). Exposing those extracted
>> bits should be easy enough. Can you file a bug at Product=Virtualization Tools
>>  Component=virtio-win ?
> 
> Done: https://bugzilla.redhat.com/show_bug.cgi?id=1219042
> 
>> However I'd suggest libosinfo still controls the URL, even if it's just a
>> redirect to the new bits. And I would also suggest that the URL only points at
>> known tested versions, since it's plausible the automated builds could be
>> completely busted sometimes, they will often hit the public repo before anyone
>> but the developer has tested them
> 
> Hm.. true but can't you separate the tested ones from completely
> untested newly build ones on http://alt.fedoraproject.org itself? The
> thing is being incharge on the whole thing, you'd be far less likely
> to notice new versions available (and also be the best judge of which
> ones can and cant be marked as stable/tested). Also we don't currently
> have any canonical location for these drivers.
> 

Check the fedora wiki page, we do have links for stable vs. latest. Stable
points to the build that roughly correlates with what was shipped with the
latest public RHEL release, so they should be reasonably trustworthy. But I
say reasonably because I don't think RHEL QE is testing libosinfo autoinstall
or anything

However... I want to avoid this situation:

- stable link is updated
- boxes installs are now busted for, say, winxp
- panic ensues, much scrambling to get the bug fixed and update the stable/ link

If instead libosinfo/boxes had its own stable link like libosinfo.org/virtio,
it could point to the virtio-win stable/ link by default, but if a nasty
regression is found, you could change libosinfo.org/virtio to point back to
the old working repo while we wait for an update

Thanks,
Cole