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(a)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(a)linux.vnet.ibm.com> wrote:
>>>>
>>>>> On 27.02.2018 13:35, Nir Soffer wrote:
>>>>>> בתאריך יום ג׳, 27 בפבר׳ 2018, 13:25, מאת Dan Horák
>>>>>> <dan(a)danny.cz>:
>>>>>>
>>>>>>> On Tue, 27 Feb 2018 10:13:15 +0100
>>>>>>> Viktor Mihajlovski <mihajlov(a)linux.vnet.ibm.com>
wrote:
>>>>>>>
>>>>>>>> On 27.02.2018 01:26, Nir Soffer wrote:
>>>>>>>>> בתאריך יום ב׳, 26 בפבר׳ 2018, 22:10, מאת Yaniv Kaul
>>>>>>>>> <ykaul(a)redhat.com>:
>>>>>>>>>
>>>>>>>>>> On Mon, Feb 26, 2018 at 7:17 PM, Viktor
Mihajlovski <
>>>>>>>>>> mihajlov(a)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