[ovirt-devel] FC27 updates broken for ovirt-4.2

[Cole Robinson]

On 02/28/2018 03:39 AM, Dan Horák wrote:
> On Tue, 27 Feb 2018 16:26:28 -0500
> Cole Robinson <crobinso at redhat.com> wrote:
> 
>> On 02/27/2018 08:03 AM, Dan Horák wrote:
>>> On Tue, 27 Feb 2018 13:54:06 +0100
>>> Viktor Mihajlovski <mihajlov at linux.vnet.ibm.com> wrote:
>>>
>>>> On 27.02.2018 13:35, Nir Soffer wrote:
>>>>> בתאריך יום ג׳, 27 בפבר׳ 2018, 13:25, מאת Dan Horák
>>>>>  ‏<dan at danny.cz>:
>>>>>
>>>>>> On Tue, 27 Feb 2018 10:13:15 +0100
>>>>>> Viktor Mihajlovski <mihajlov at linux.vnet.ibm.com> wrote:
>>>>>>
>>>>>>> On 27.02.2018 01:26, Nir Soffer wrote:
>>>>>>>> בתאריך יום ב׳, 26 בפבר׳ 2018, 22:10, מאת Yaniv Kaul
>>>>>>>>  ‏<ykaul at redhat.com>:
>>>>>>>>
>>>>>>>>> On Mon, Feb 26, 2018 at 7:17 PM, Viktor Mihajlovski <
>>>>>>>>> mihajlov at linux.vnet.ibm.com> wrote:
>>>>>>>>>
>>>>>>>>>> I just tried to update the ovirt packages on my FC27 host,
>>>>>>>>>> but failed due to https://gerrit.ovirt.org/#/c/87628/
>>>>>>>>>>
>>>>>>>>>> vdsm now requires libvirt >= 3.10.0-132 but Fedora 27 has
>>>>>>>>>> only 3.7.0-4 the moment.
>>>>>>>>>>
>>>>>>>>>> It's generic Fedora 27, but since I run on s390,
>>>>>>>>>> cross-posting to s390 list.
>>>>>>>>>>
>>>>>>>>>> I guess there's good reason to require libvirt 3.10. Is there
>>>>>>>>>> any chance that we can get libvirt updated for Fedora 27?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Perhaps use the virt-preview[1] repo for now?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes, we require virt-preview for Fedora. This is why that patch
>>>>>>>> did not fail in the CI.
>>>>>>> Makes sense, unfortunately virt-preview doesn't contains s390
>>>>>>> binaries at this point in time. Would be great if at least
>>>>>>> libvirt and qemu could be built for s390.
>>>>>>
>>>>>> looks like it's even x86_64 only, /me wonders what it would
>>>>>> require to offer other arches (aarch64, ppc64le, s390x) as well
>>>>>>
>>>>>
>>>>> If we need to support platform not supported in virt-preview, we
>>>>> need to chage the requirement so it is used only on x86_64.
>>>>>
>>>>> Victor, would you like to send a patch?
>>>> I believe there was a good reason to bump the libvirt requirement
>>>> in the vdsm package (some bugfix). Ideally, virt-preview should be
>>>> build for s390 as well.
>>>> If I'm not mistaking, the script
>>>> https://github.com/crobinso/build-fedora-virt-preview is used to
>>>> build the RPMs and populate the repository.
>>>>
>>>> Dan, Cole: what would it take to run this on the fedora-390 build
>>>> machine?
>>>
>>> after a brief look the script needs to be made multi-arch-aware (it
>>> hard-codes x86_64 in some places), when it calls mock, and then it
>>> needs some HW (we have ppc64le and s390x even now, aarch64 might
>>> take a while), overall it looks doable to me. Cole, what do you
>>> think?
>>>
>>
>> I'm open to the idea in theory but in practice right now the script
>> uses mock locally so it's basically tied to the one build machine I
>> use which is x86. I have arm32 and aarch64 hardware locally but TBH I
>> have very little interest in running a build farm and dealing with
>> all the issues of connecting to remote machines, pulling down build
>> output, etc. In fact I've been meaning to move virt-preview to copr
>> for a long while which is going to tie it even deeper to x86, this
>> would make virt-preview easier to enable and let me scrap much of my
>> custom code for building/uploading repo contents.
> 
> copr would give us ppc64le and probably aarch64 too in addition to x86,
> but can't help with s390. We already have build infra internally
> covering all arches driven by Jenkins, with plans to move the workloads
> to CentOS infra. I'll look whether or how it could be used for
> multi-arch virt-preview repos. 
> 
>> We could re-implement it using koji scratch builds which have multiple
>> arch support nowadays but I did that in the past for x86 and I recall
>> feeling it was quite brittle, though I don't remember the details,
>> maybe it was just my implementation.
> 
> I suspect the problem with koji scratch builds in this case is that
> they can't be used in buildroots, which the virt-preview stack requires.
> 

Good point, but generally virt-preview packages are very loosely coupled
and don't have strong version dependencies on one another. Occasionally
a small dependency needs to be updated like libiscsi or libcacard but in
fact it's been a long time since that's been required.

- Cole