[ovirt-devel] [vdsm] s390 draft patches submitted for review

Sun Sep 24 07:39:44 UTC 2017

On Wed, Sep 20, 2017 at 11:04 PM, Michal Skrivanek <
michal.skrivanek at redhat.com> wrote:

>
> On 20 Sep 2017, at 16:12, Viktor Mihajlovski <mihajlov at linux.vnet.ibm.com>
> wrote:
>
> On 20.09.2017 15:40, Michal Skrivanek wrote:
>
>
> On 19 Sep 2017, at 14:08, Viktor Mihajlovski <mihajlov at linux.vnet.ibm.com>
> wrote:
>
> On 18.09.2017 17:52, Juan Hernández wrote:
>
> On 09/18/2017 05:31 PM, Viktor Mihajlovski wrote:
>
> Hi,
>
> I have submitted a topic branch containing the changes necessary to
> enable support for the s390 arch in VDSM and would appreciate your
> feedback, not only for the code, but also on the procedure:
>
> 1. I've submitted the patches as draft, following the suggestions on the
> homepage. Not sure whether this is really required.
>
> 2. The individual commits are actually tiny, let me know whether this is
> OK, or you prefer a single commit.
>
> 3. Topic branch here: https://gerrit.ovirt.org/#/q/topic:s390-base
>
>
> Note that draft changes are generally OK, but they have the inconvenient
> that they are invisible for people that isn't explicitly added as
> reviewers. So you will need to either promote them to regular patches,
> maybe adding a [WIP] prefix to the subject, or else explicitly add
> reviewers, otherwise nobody will see them.
>
> Thanks for the clarification, I have done as you suggested. Looking
> forward for comments.
>
>
> Hi Viktor,
> thank you for the contribution! It looks good so far, some of the patches
> are already in a good shape, feel free to remove the WIP prefix.
> Size of the patches is also quite matching the typical scope of each
> patch, at least for vdsm.
>
> Do you intend to work on ovirt-engine component as well? If yes then it
> would be great if you share the areas which you expect will need to change,
> or perhaps some other higher level overview of what kind of changes in
> general are required in oVirt to have a complete s390 support
>
> Hi Michal,
>
> thanks for the feedback. I'll have to clean up the vdsm/libvirt stuff
> first. There's still an issue with NUMA on s390 I have to solve…
>
>
> sure, it’s the one to start with. Are other system dependencies (qemu,
> libvirt, other)?
>
>
> Once I'm done with vdsm, I'll provide patches for ovirt-engine. As a
>
>
> that’s great!
>
> prerequisite for that I need to update ovirt-engine-api-model (new
> architecture and a new watchdog device type).
>
>
> regarding watchdog…we have an overdue plan/intent to use pvpanic instead
> of watchdog devices. They are not widely used anyway. So I wonder if there
> are plans to support pvpanic on s390 at the qemu/libvirt level and
> (separately) whether a watchdog is an important item for s390 users
>
> Most of the changes have to do with the s390 cpu type handling, nothing
> really fancy.
>
> Maybe a side discussion: I use ovirt-host-deploy to turn a Fedora
> installation into a hypervisor. This worked (with minor changes) well
> for Fedora 25, but fails for Fedora 26. This is because F26 uses DNF
> version 3 whereas the otopi/python dnf plugin refuses to work with DNF
> != 1. Has anyone been hit by that before, and if so, any plans to fix that?
>
>
> yeah, unfortunately we are a bit behind on moving to new dnf and due to
> qemu and libvirt features we are forced to move out of F25 to F26….which is
> not ideal - F25 is no longer enough to run, but you can’t really deploy
> ovirt on F26. A fix is not expected to happen for some time and I’m afraid
> for the timebeing you’d need to work around that manually, perhaps
> deploying on F25 and then upgrading to F26 would work.
> We’re mostly focusing on EL platform, it may also make sense to work on
> top of EL 7.4 with custom QEMU/libvirt (I’m assuming you do need some
> bleeding edge changes there)
>

Are you sure about "DNF version 3"? "bin/dnf-3" is "dnf using python3".

For dnf-2 support, we have:

https://bugzilla.redhat.com/show_bug.cgi?id=1455452

Currently targetted to oVirt 4.3.