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

[Cole Robinson]

On 03/01/2018 09:49 AM, Viktor Mihajlovski wrote:
> On 28.02.2018 17:27, Cole Robinson wrote:
>> 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
>>
> Hi Cole, for the time being I've patched vdsm to require libvirt 3.7.0-4
> (which contains the hotplug patch required by vdsm). Unfortunately, this
> release is still only in updates-testing, which lead to a build failure
> on ovirt Jenkins.
> Do you have an idea by when 3.7.0-4 will be propagated to fedora updates?
> Thanks!
> 

I submitted it for 'updates' yesterday, so whenever the next compose is.

Is this about vdsm packages in fedora, or an external repo that builds
packages for upstream?

- Cole