<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 10, 2017 at 4:10 AM, Barak Korren <span dir="ltr"><<a href="mailto:bkorren@redhat.com" target="_blank">bkorren@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 24 November 2017 at 14:36, Dan Horák <<a href="mailto:dan@danny.cz">dan@danny.cz</a>> wrote:<br>
</span><div><div class="h5">> On Fri, 24 Nov 2017 13:16:53 +0200<br>
> Barak Korren <<a href="mailto:bkorren@redhat.com">bkorren@redhat.com</a>> wrote:<br>
><br>
>> On 24 November 2017 at 11:05, Viktor Mihajlovski<br>
>> <<a href="mailto:mihajlov@linux.vnet.ibm.com">mihajlov@linux.vnet.ibm.com</a>> wrote:<br>
>> > On 21.11.2017 11:26, Dan Horák wrote:<br>
>> > [...]<br>
>> >>> qemu s390x emulation does not work with code compiled for z12.<br>
>> >>> Would a real virtual machine be what you need?<br>
>> >>> The Fedora team DOES have access to a z13. Not sure how much<br>
>> >>> resources are available, but can you contact Dan Horak (on cc) if<br>
>> >>> there is enough spare capacity.<br>
>> >><br>
>> >> Christian is right, we have a publicly accessible guest running<br>
>> >> Fedora on the Marist College z13 mainframe. It's currently used by<br>
>> >> ~5 projects (for example glibc and qemu) as their build and CI<br>
>> >> host, so adding another project depends how intensive ovirt's<br>
>> >> usage would be.<br>
>> > As a first step one could only build the packages needed for the KVM<br>
>> > host. At this point in time that would be vdsm and ovirt-host, both<br>
>> > are building rather quickly.<br>
>> > It should be possible to ensure that only these are built on a s390<br>
>> > system using appropriate node filters.<br>
>> > [...]<br>
>><br>
>> We can get more accurate data by looking at the ppc64c build history<br>
>> (We support ppc64le only for hypervisor usage, similar to what is<br>
>> intended for s390).<br>
>> Here is the history for vdsm:<br>
>> <a href="http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-el7-ppc64le/buildTimeTrend" rel="noreferrer" target="_blank">http://jenkins.ovirt.org/job/<wbr>vdsm_master_build-artifacts-<wbr>el7-ppc64le/buildTimeTrend</a><br>
>> (~20 builds a day taking 1-2 minutes each)<br>
>> And here is the one for ovirt-host:<br>
>> <a href="http://jenkins.ovirt.org/job/ovirt-host_master_check-patch-el7-ppc64le/buildTimeTrend" rel="noreferrer" target="_blank">http://jenkins.ovirt.org/job/<wbr>ovirt-host_master_check-patch-<wbr>el7-ppc64le/buildTimeTrend</a><br>
>> (only 1 build in history, taking 3-4 minutes)<br>
>><br>
>> Looking at what else we have building on ppc64le:<br>
>> <a href="http://jenkins.ovirt.org/search/?q=master_build-artifacts-el7-ppc64le" rel="noreferrer" target="_blank">http://jenkins.ovirt.org/<wbr>search/?q=master_build-<wbr>artifacts-el7-ppc64le</a><br>
>> I can also see ioprocess with is a vdsm dependency, and the SDK which<br>
>> is probably not really needed.<br>
>> So for ioprocess:<br>
>> <a href="http://jenkins.ovirt.org/job/ioprocess_master_build-artifacts-el7-ppc64le/buildTimeTrend" rel="noreferrer" target="_blank">http://jenkins.ovirt.org/job/<wbr>ioprocess_master_build-<wbr>artifacts-el7-ppc64le/<wbr>buildTimeTrend</a><br>
>> I'd say its very rarely built.<br>
>><br>
>> So we end up with ~20 1-2 minute builds a day (Timed but the amount of<br>
>> Fedora versions we want to support, but what will probably be just<br>
>> one), with the rest being a statistical error...<br>
>><br>
>> I wonder about sharing a VM with other project though. We do use mock<br>
>> for running the build script so the build itself should be fairly<br>
>> isolated, but we have some of our own wrapper scripts around mock that<br>
>> do things trying to keep build dependencies in the chroot cache over<br>
>> time. We're also incompatible with mock's new systemd-nspawn backend,<br>
>> so we force it to work with the older chroot-based backend. If other<br>
>> projects are using mock as well, I wonder if we may end up with race<br>
>> conditions arising from shared use of /var/lib/mock.<br>
><br>
> it should work fine<br>
><br>
>> Bottom line - we may end up being a little noisy neighbours if we<br>
>> share a VM, but we can try that and see what happens, how to we move<br>
>> foreward with trying that?<br>
><br>
> ok, I'm pretty sure we can make it work :-) Please send me your<br>
> public SSH key and preferred username, then I'll set up you an account<br>
> for you and we can work on the remaining details.<br>
><br>
<br>
</div></div>An update for everyone woh may have been watching this thread - we made it work.<br>
<br>
With Dan's kind help we've attached an s390x VM to oVirt's CI<br>
infrastructure. I've then gone ahead and made some code changes to<br>
make our CI code play nice on it (So far we just assumed we own the<br>
execution slaves and can do what we want on them...). Following that<br>
I've gone ahead and added the basic configuration needed to make the<br>
oVirt CI system support s390x jobs.<br>
<br>
For now we only support using Fedora 26 on s390x. Please let me know<br>
if other distributions are desired.<br>
<br>
The code changes I've made had already been tested and are now pending<br>
code review:<br>
<a href="https://gerrit.ovirt.org/c/85219" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/c/<wbr>85219</a><br>
<a href="https://gerrit.ovirt.org/c/85221" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/c/<wbr>85221</a><br>
<br>
Once those patches are merged it will become possible to add s390x<br>
jobs to any oVirt project by adding '390x' to the list of<br>
architectures targeted by the project in the JJB YAML, as well as<br>
setting the 'node_filter' to be 's390x' for that architecture.<br></blockquote><div><br></div><div>Great job all! So I guess the question is, for those of us that maintain oVirt projects, are there any that we know need s390x support added for?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="im HOEnZb"><br>
--<br>
Barak Korren<br>
RHV DevOps team , RHCE, RHCi<br>
Red Hat EMEA<br>
<a href="http://redhat.com" rel="noreferrer" target="_blank">redhat.com</a> | TRIED. TESTED. TRUSTED. | <a href="http://redhat.com/trusted" rel="noreferrer" target="_blank">redhat.com/trusted</a><br>
</span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:uppercase"><span>GREG</span> <span>SHEREMETA</span></p><p style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:10px;margin:0px 0px 4px;text-transform:uppercase"><span>SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX</span><span style="color:rgb(170,170,170);margin:0px"></span></p><p style="font-family:overpass,sans-serif;margin:0px;font-size:10px;color:rgb(153,153,153)"><a href="https://www.redhat.com/" style="color:rgb(0,136,206);margin:0px" target="_blank">Red Hat NA<span><br><br></span></a></p><p style="font-family:overpass,sans-serif;margin:0px 0px 6px;font-size:10px;color:rgb(153,153,153)"><span style="margin:0px;padding:0px"><a href="mailto:gshereme@redhat.com" style="color:rgb(0,136,206);margin:0px" target="_blank">gshereme@redhat.com</a> </span> <span>IRC: <span>gshereme</span></span></p><table border="0" style="color:rgb(0,0,0);font-family:overpass,sans-serif;font-size:medium"><tbody><tr><td width="100px"><a href="https://red.ht/sig" target="_blank"><img src="https://www.redhat.com/files/brand/email/sig-redhat.png" width="90" height="auto"></a></td></tr></tbody></table></div></div></div></div></div></div></div></div></div>
</div></div>