oVirt s390x support - some questions for maintainers
Hi to all project maintainers, As you may know, over the last few months the oVirt project had got some code contributions geared towards enabling the use of s390x (Mainframe) machines as hypervisor hosts. As you may also know, if you've followed the relevant thread, some work had been done in collaboration with the Fedora community to enable os390x support in oVirt`s CI system. We're now at the point where we can take the final step and enable automated builds of node components for s390x/fc27. Looking at what we curently build for ppc64le, I already took the time and submitted patches to enable build jobs for vdsm [2], ovirt-host [3], and ioprocess [4]. The relevant maintainers should have had these patches land in thair inbpx already. Few questions remain however: 1. When would be the best time to merge the patches mentioned above? Given that some of the projects do not support fc27 yet, that the new build jobs may raise issues and that the 4.2 release is fast approaching, the right timing should be considered carefully. 2. Which additional projects need to be build? I can see we build some SDK components for ppc64le as wel, are those dependences of vdsm? Will we need to build then for s390x? [1]: http://jenkins.ovirt.org/search/?q=master_build-artifacts-el7-ppc64le [2]: https://gerrit.ovirt.org/c/85487 [3]: https://gerrit.ovirt.org/c/85486 [4]: https://gerrit.ovirt.org/c/85485 -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
On Fri, Dec 15, 2017 at 10:30 PM Barak Korren <bkorren@redhat.com> wrote:
Hi to all project maintainers,
As you may know, over the last few months the oVirt project had got some code contributions geared towards enabling the use of s390x (Mainframe) machines as hypervisor hosts.
As you may also know, if you've followed the relevant thread, some work had been done in collaboration with the Fedora community to enable os390x support in oVirt`s CI system.
We're now at the point where we can take the final step and enable automated builds of node components for s390x/fc27. Looking at what we curently build for ppc64le, I already took the time and submitted patches to enable build jobs for vdsm [2], ovirt-host [3], and ioprocess [4]. The relevant maintainers should have had these patches land in thair inbpx already.
Few questions remain however: 1. When would be the best time to merge the patches mentioned above? Given that some of the projects do not support fc27 yet, that the new build jobs may raise issues and that the 4.2 release is fast approaching, the right timing should be considered carefully.
We should prepare a fedora 27 build for all projects before we enable the jobs in the CI. But if we can disable problematic jobs in the CI easily (and it seems we can), I think this is not a problem. You can merge the ioprocess change now if you like.
2. Which additional projects need to be build? I can see we build some SDK components for ppc64le as wel, are those dependences of vdsm? Will we need to build then for s390x?
For vdsm we need: - ioprocess (nsoffer) - ovirt-imageio-daemon (derez) - ovirt-imageio-common (derez) - pthreading (ybronhei) - subprocess32 (sbonazzo?) For engine: - ovirt-imageio-common - ovirt-imageio-proxy This is only (some) the components that we build. We have also tons of dependencies that are part of Fedora (e.g. sanlock, libvirt). I hope these projects are built for s390x. Added some maintainers. Nir
[1]: http://jenkins.ovirt.org/search/?q=master_build-artifacts-el7-ppc64le [2]: https://gerrit.ovirt.org/c/85487 [3]: https://gerrit.ovirt.org/c/85486 [4]: https://gerrit.ovirt.org/c/85485
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On 16 December 2017 at 00:53, Nir Soffer <nsoffer@redhat.com> wrote:
On Fri, Dec 15, 2017 at 10:30 PM Barak Korren <bkorren@redhat.com> wrote:
Hi to all project maintainers,
As you may know, over the last few months the oVirt project had got some code contributions geared towards enabling the use of s390x (Mainframe) machines as hypervisor hosts.
As you may also know, if you've followed the relevant thread, some work had been done in collaboration with the Fedora community to enable os390x support in oVirt`s CI system.
We're now at the point where we can take the final step and enable automated builds of node components for s390x/fc27. Looking at what we curently build for ppc64le, I already took the time and submitted patches to enable build jobs for vdsm [2], ovirt-host [3], and ioprocess [4]. The relevant maintainers should have had these patches land in thair inbpx already.
Few questions remain however: 1. When would be the best time to merge the patches mentioned above? Given that some of the projects do not support fc27 yet, that the new build jobs may raise issues and that the 4.2 release is fast approaching, the right timing should be considered carefully.
We should prepare a fedora 27 build for all projects before we enable the jobs in the CI. But if we can disable problematic jobs in the CI easily (and it seems we can), I think this is not a problem.
I don't want to have the code in 'master' diverge from what actually exists in jenkins.
You can merge the ioprocess change now if you like.
Maybe its better to make sure fc27/x86_64 builds first? Please state your intent on the relevant patch.
2. Which additional projects need to be build? I can see we build some SDK components for ppc64le as wel, are those dependences of vdsm? Will we need to build then for s390x?
For vdsm we need: - ioprocess (nsoffer) - ovirt-imageio-daemon (derez) - ovirt-imageio-common (derez) - pthreading (ybronhei) - subprocess32 (sbonazzo?)
I wonder how come the last 4 don't have ppc64le builds. The last 2 don't seem to even have proper build jobs.
For engine:
AFAIK there is no intention to support running engine on anything other then x86_64 at this point.
This is only (some) the components that we build. We have also tons of dependencies that are part of Fedora (e.g. sanlock, libvirt). I hope these projects are built for s390x.
There is a full fedora build for s390x, so I suppose those are available there. Also, those are all mentioned in vdsm.spec right? So build-artifacts will not pass if they are missing right? -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
2017-12-17 8:38 GMT+01:00 Barak Korren <bkorren@redhat.com>:
On 16 December 2017 at 00:53, Nir Soffer <nsoffer@redhat.com> wrote:
On Fri, Dec 15, 2017 at 10:30 PM Barak Korren <bkorren@redhat.com> wrote:
Hi to all project maintainers,
As you may know, over the last few months the oVirt project had got some code contributions geared towards enabling the use of s390x (Mainframe) machines as hypervisor hosts.
As you may also know, if you've followed the relevant thread, some work had been done in collaboration with the Fedora community to enable os390x support in oVirt`s CI system.
We're now at the point where we can take the final step and enable automated builds of node components for s390x/fc27. Looking at what we curently build for ppc64le, I already took the time and submitted patches to enable build jobs for vdsm [2], ovirt-host [3], and ioprocess [4]. The relevant maintainers should have had these patches land in thair inbpx already.
Few questions remain however: 1. When would be the best time to merge the patches mentioned above?
Given
that some of the projects do not support fc27 yet, that the new build jobs may raise issues and that the 4.2 release is fast approaching, the right timing should be considered carefully.
We should prepare a fedora 27 build for all projects before we enable the jobs in the CI. But if we can disable problematic jobs in the CI easily (and it seems we can), I think this is not a problem.
I don't want to have the code in 'master' diverge from what actually exists in jenkins.
You can merge the ioprocess change now if you like.
Maybe its better to make sure fc27/x86_64 builds first? Please state your intent on the relevant patch.
2. Which additional projects need to be build? I can see we build some SDK components for ppc64le as wel, are those dependences of vdsm? Will we need to build then for s390x?
For vdsm we need: - ioprocess (nsoffer) - ovirt-imageio-daemon (derez) - ovirt-imageio-common (derez) - pthreading (ybronhei) - subprocess32 (sbonazzo?)
I wonder how come the last 4 don't have ppc64le builds.
These are noarch: - ovirt-imageio-daemon (derez) - ovirt-imageio-common (derez) These are provided by Fedora and CentOS Virt SIG - pthreading (ybronhei) - subprocess32 (sbonazzo?)
The last 2 don't seem to even have proper build jobs.
For engine:
AFAIK there is no intention to support running engine on anything other then x86_64 at this point.
This is only (some) the components that we build. We have also tons of dependencies that are part of Fedora (e.g. sanlock, libvirt). I hope these projects are built for s390x.
There is a full fedora build for s390x, so I suppose those are available there. Also, those are all mentioned in vdsm.spec right? So build-artifacts will not pass if they are missing right?
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
-- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
2017-12-15 23:53 GMT+01:00 Nir Soffer <nsoffer@redhat.com>:
On Fri, Dec 15, 2017 at 10:30 PM Barak Korren <bkorren@redhat.com> wrote:
Hi to all project maintainers,
As you may know, over the last few months the oVirt project had got some code contributions geared towards enabling the use of s390x (Mainframe) machines as hypervisor hosts.
As you may also know, if you've followed the relevant thread, some work had been done in collaboration with the Fedora community to enable os390x support in oVirt`s CI system.
We're now at the point where we can take the final step and enable automated builds of node components for s390x/fc27. Looking at what we curently build for ppc64le, I already took the time and submitted patches to enable build jobs for vdsm [2], ovirt-host [3], and ioprocess [4]. The relevant maintainers should have had these patches land in thair inbpx already.
Few questions remain however: 1. When would be the best time to merge the patches mentioned above? Given that some of the projects do not support fc27 yet, that the new build jobs may raise issues and that the 4.2 release is fast approaching, the right timing should be considered carefully.
We should prepare a fedora 27 build for all projects before we enable the jobs in the CI. But if we can disable problematic jobs in the CI easily (and it seems we can), I think this is not a problem.
You can merge the ioprocess change now if you like.
2. Which additional projects need to be build? I can see we build some SDK components for ppc64le as wel, are those dependences of vdsm? Will we need to build then for s390x?
For vdsm we need: - ioprocess (nsoffer) - ovirt-imageio-daemon (derez) - ovirt-imageio-common (derez) - pthreading (ybronhei) - subprocess32 (sbonazzo?)
subprocess32 is included in Fedora https://koji.fedoraproject.org/koji/packageinfo?packageID=15499 I just rebuild it for Virt SIG: http://cbs.centos.org/koji/packageinfo?packageID=3725
For engine: - ovirt-imageio-common - ovirt-imageio-proxy
This is only (some) the components that we build. We have also tons of dependencies that are part of Fedora (e.g. sanlock, libvirt). I hope these projects are built for s390x.
Added some maintainers.
Nir
[1]: http://jenkins.ovirt.org/search/?q=master_build- artifacts-el7-ppc64le [2]: https://gerrit.ovirt.org/c/85487 [3]: https://gerrit.ovirt.org/c/85486 [4]: https://gerrit.ovirt.org/c/85485
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
2017-12-15 21:29 GMT+01:00 Barak Korren <bkorren@redhat.com>:
Hi to all project maintainers,
As you may know, over the last few months the oVirt project had got some code contributions geared towards enabling the use of s390x (Mainframe) machines as hypervisor hosts.
As you may also know, if you've followed the relevant thread, some work had been done in collaboration with the Fedora community to enable os390x support in oVirt`s CI system.
We're now at the point where we can take the final step and enable automated builds of node components for s390x/fc27. Looking at what we curently build for ppc64le, I already took the time and submitted patches to enable build jobs for vdsm [2], ovirt-host [3], and ioprocess [4]. The relevant maintainers should have had these patches land in thair inbpx already.
Few questions remain however: 1. When would be the best time to merge the patches mentioned above? Given that some of the projects do not support fc27 yet, that the new build jobs may raise issues and that the 4.2 release is fast approaching, the right timing should be considered carefully.
The major concern I have is on the patch dropping sudo requirements at https://gerrit.ovirt.org/#/c/85219/ If you verified that it doesn't break CI, I think you can merge right after 4.2.0 GA.
2. Which additional projects need to be build? I can see we build some SDK components for ppc64le as wel, are those dependences of vdsm? Will we need to build then for s390x?
They're not vdsm deps, but please build them too.
[1]: http://jenkins.ovirt.org/search/?q=master_build-artifacts-el7-ppc64le [2]: https://gerrit.ovirt.org/c/85487 [3]: https://gerrit.ovirt.org/c/85486 [4]: https://gerrit.ovirt.org/c/85485
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- SANDRO BONAZZOLA ASSOCIATE MANAGER, SOFTWARE ENGINEERING, EMEA ENG VIRTUALIZATION R&D Red Hat EMEA <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
On 15.12.2017 21:29, Barak Korren wrote:
Hi to all project maintainers,
As you may know, over the last few months the oVirt project had got some code contributions geared towards enabling the use of s390x (Mainframe) machines as hypervisor hosts.
As you may also know, if you've followed the relevant thread, some work had been done in collaboration with the Fedora community to enable os390x support in oVirt`s CI system.
We're now at the point where we can take the final step and enable automated builds of node components for s390x/fc27. Looking at what we curently build for ppc64le, I already took the time and submitted patches to enable build jobs for vdsm [2], ovirt-host [3], and ioprocess [4]. The relevant maintainers should have had these patches land in thair inbpx already.
Few questions remain however: 1. When would be the best time to merge the patches mentioned above? Given that some of the projects do not support fc27 yet, that the new build jobs may raise issues and that the 4.2 release is fast approaching, the right timing should be considered carefully. 2. Which additional projects need to be build? I can see we build some SDK components for ppc64le as wel, are those dependences of vdsm? Will we need to build then for s390x?
[1]: http://jenkins.ovirt.org/search/?q=master_build-artifacts-el7-ppc64le [2]: https://gerrit.ovirt.org/c/85487 [3]: https://gerrit.ovirt.org/c/85486 [4]: https://gerrit.ovirt.org/c/85485
Since 4.2 is out, it would be great if we could merge the ovirt-host [3] first and - if successfull - vdsm [2]. Should there be failures on s390x I would have a look. -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski
On 3 January 2018 at 15:41, Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> wrote:
On 15.12.2017 21:29, Barak Korren wrote:
Hi to all project maintainers,
As you may know, over the last few months the oVirt project had got some code contributions geared towards enabling the use of s390x (Mainframe) machines as hypervisor hosts.
As you may also know, if you've followed the relevant thread, some work had been done in collaboration with the Fedora community to enable os390x support in oVirt`s CI system.
We're now at the point where we can take the final step and enable automated builds of node components for s390x/fc27. Looking at what we curently build for ppc64le, I already took the time and submitted patches to enable build jobs for vdsm [2], ovirt-host [3], and ioprocess [4]. The relevant maintainers should have had these patches land in thair inbpx already.
Few questions remain however: 1. When would be the best time to merge the patches mentioned above? Given that some of the projects do not support fc27 yet, that the new build jobs may raise issues and that the 4.2 release is fast approaching, the right timing should be considered carefully. 2. Which additional projects need to be build? I can see we build some SDK components for ppc64le as wel, are those dependences of vdsm? Will we need to build then for s390x?
[1]: http://jenkins.ovirt.org/search/?q=master_build-artifacts-el7-ppc64le [2]: https://gerrit.ovirt.org/c/85487 [3]: https://gerrit.ovirt.org/c/85486 [4]: https://gerrit.ovirt.org/c/85485
Since 4.2 is out, it would be great if we could merge the ovirt-host [3] first and - if successfull - vdsm [2]. Should there be failures on s390x I would have a look.
Both these project had issues the last time we enabled FC27 builds for them, so I'd like to see some core maintainers in the loop. I'm running an fc27x86_64 build of vdsm master atm, lets see if that passes at least; http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-fc27-x86_64/46/ -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
On 03.01.2018 15:11, Barak Korren wrote: [...]
[1]: http://jenkins.ovirt.org/search/?q=master_build-artifacts-el7-ppc64le [2]: https://gerrit.ovirt.org/c/85487 [3]: https://gerrit.ovirt.org/c/85486 [4]: https://gerrit.ovirt.org/c/85485
Since 4.2 is out, it would be great if we could merge the ovirt-host [3] first and - if successfull - vdsm [2]. Should there be failures on s390x I would have a look.
Both these project had issues the last time we enabled FC27 builds for them, so I'd like to see some core maintainers in the loop. fair enough ... although I'm baffled to hear there was a ovirt-host build failure (since the RPM build is a no-op).
I'm running an fc27x86_64 build of vdsm master atm, lets see if that passes at least; http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-fc27-x86_64/46/
hooray, it passed :) -- Mit freundlichen Grüßen/Kind Regards Viktor Mihajlovski
participants (4)
-
Barak Korren -
Nir Soffer -
Sandro Bonazzola -
Viktor Mihajlovski