On Fri, Aug 23, 2019 at 6:41 PM Michal Skrivanek <michal.skrivanek@redhat.com> wrote:

...

I agree about the speed, OST is awfully slow, almost unusable. But other than that, not really, I discourage you from neglecting functional fixes and just focuse on unit tests.
It is important to fix actual functional problems

We are focusing on small and fast functional tests doing real flows with (mostly) real storage.

I think this give be the best value. Being able to verify changes in seconds means you can

move fast - safely.

The most important actual issue we have now is tests failing on pyhton 3, for example

block storage tests:

https://gerrit.ovirt.org/q/topic:py3-blocksd

When these tests will pass, there is a chance that block storage will work in OST.

A bigger problem is code without any tests like the tasks framework, SPM flows and

legacy storage flows. We work now on the tasks framework:

https://gerrit.ovirt.org/q/topic:py3_task

We also worked on the outOfProcess module which is the foundation of all file based

storage domains:

https://gerrit.ovirt.org/q/topic:py3-oop

This work reveled 2 bugs in ioproess, one fixed now:

https://gerrit.ovirt.org/q/topic:ioprocess_access

Coincidentally, just now I got a working OST on py3/RHEL8 just with a couple of workarounds/skips. So we should soon be able to have this (slow) safeguard in place and we’ll be able to eliminate py2/el7 code.

We need to keep python 2.7 code until we finish porting to python 3, and maybe later.

It will be hard to support 4.3 if master code is not compatible with python 2.

Nir