[ovirt-devel] Adding s390 support to oVirt

[Peter Robinson]

On Fri, Nov 17, 2017 at 8:45 AM, Viktor Mihajlovski
<mihajlov at linux.vnet.ibm.com> wrote:
> On 16.11.2017 18:27, Barak Korren wrote:
>> On 16 November 2017 at 18:52, Viktor Mihajlovski
>> <mihajlov at linux.vnet.ibm.com> wrote:
>>>
>>> Short update, with yesterday's API model 4.2.25 release, there's basic
>>> support for s390 available in ovirt-engine. At this point in time, there
>>> are no ovirt yum repositories for the s390x architecture - not sure what
>>> the process would be to add s390x repositories and how to build the
>>> binary RPMs at least for the host packages (i.e. vdsm-*). Maybe it would
>>> possible to use the s390-koji infrastructure used to build Fedora for s390x?
>>
>> Koji is very opinionated about how RPMs and specfiles should look,
>> AFAIK A pretty massive amount of work would be needed to make
>> everything that is needed for a node to build on it, and then we would
>> end up with a process that is quite different with how we currently do
>> builds for other platforms.
>>
>> (I might be wrong about this, since some oVirt packages get also built
>> as part of the CentOS virt SIG, and that is done using Koji as well)
>>
>> More specifically, Koji usually assumes the starting point for the
>> build process would be a specfile, while in oVirt we typically
>> generated the specfile and then the RPM as part of a bigger build
>> process.
>>
>> Does fedora have an s390x server associated to it?
> There's a build system for Fedora on s390x:
> https://s390.koji.fedoraproject.org/koji

That is now deprecated, all the architectures including s390x build in
the primary Fedora koji infra

https://koji.fedoraproject.org/koji/packageinfo?packageID=12944

You'd just have to make the appropriate changes to the vdsm package
and it would build for Fedora on s390x

>> We do use the same basic environment setup tool - mock - as the basis
>> of our build infrastructure, so if Fedora is actually emulating s390x
>> is some way while using mock, we might be able to do the same thing.
>>
>> Just for general knowledge, the process for building oVirt repos, is
>> to have *-build-artifacts-* jobs for each project that build RPM's
>> after patches get merged, and then have the change-queue to collect
>> the built packages, rung them through ovirt-system-tests (a.k.a. OST)
>> and finally deposit them into the 'tested' rpoe, from which they are
>> copied nightly to the '*-snapshot' repos.
>>
>> OST only tests for CentOS 7/x86_64 ATM, but we bring along packages
>> for other distros and architectures via the same process while
>> assuming that if a package for a given commit works for CentOS
>> 7/x86_64 it would probably work for other platforms as well...
>>
> I've noticed that there's no test automation for non-x86 arches. How are
> the ppc64le packages then built and stored in the repos?

This is slowly improving, it's about having available infrastructure
and people to assist in getting it running and supporting it. For
example I believe there's now ppc64le testing in openQA now.

> Would it be conceivable to do the following?
> After a successfull build and OST of a package, take the SRPM and submit
> to s390-koji to produce the s390x binary RPMs.
> Then copy the binary RPMs into the respective repository, e.g.
> *-snapshot/rpm/el7/s390x (and update the repository metadata).

We don't currently have s390x EPEL