On Fri, Aug 23, 2019 at 6:41 PM Michal Skrivanek <
michal.skrivanek(a)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